Wikimedia: Dateidownload erschweren

ScoutX · 4. Mai 2010

Wikimedia Webseite (die noch nicht existiert)
Es soll ähnlich wie unter CSS ein Rechtsklick-Menü und ein Datei speichern unter erschwert werden.
Ist dies möglich und wenn, wie? Ich habe nichts Brauchbares im Web gefunden.
Als Alternative könnte ich ein ähnliches Interface bzw. Contentmanagement nehmen, es muss aber Wysiwyg Eigenschaften haben.
Aber auch hier wüsste ich auf Anhieb kein solches Feature.
Wichtig: Ich soll die Webseite für einen Bekannten einrichten, der praktischen nur mit Wysiwyg zurechtkommt.
Ich werde die Seite kaum pflegen, wenn überhaupt.
Ich erwarte auch wenige Änderungen. Es werden ab und an ein paar Bilder und Texte hinzukommen. Mit Wikimedia hier und da etwas ändern, wird für ihn möglich sein.

gh0st2k · 4. Mai 2010

Ich wüsste nicht wie. Alles was der User "angezeigt" bekommt, wird schließlich an ihn übertragen...
Über Javascript kann man ja das Rechtsklick-Menü unterbinden, aber um dies zu umgehen muss man nur Javascript abschalten.

#@A@B@C# · 4. Mai 2010

Wofür? ist absolut sinnlos!, du kannst es mit Javascript machen http://de.selfhtml.org/navigation/anzeige/rechte_maustaste.htm , aber erstens kann man Javascript ausschalten, zweitens kann man sich auch alles aus dem Browser cash holen......... deswegen würde ich solchen Blödsinn lassen.

MFG.

Edit: mal wieder zu spät^^

Benzer · 4. Mai 2010

Und selbst jemand der nicht die Kenntnisse hat um sich die Daten ausm Cache / Temp zu holen, macht von interessanten Dingen nen screenshot.

DjNDB · 4. Mai 2010

Rate ihm davon ab. Wenn er Inhalte anderen nicht zur Verfügung stellen möchte, dann soll er sie einfach nicht hochladen.
Praxisnäher ist wahrscheinlich, dass er seine Einstellung überdenkt. Warum soll jemand der etwas auf seiner Webseite anzeigen kann es nicht speichern dürfen?

Nuck_Chorris · 4. Mai 2010

und man kann ganz einfach im quellcode nach der source suchen und von da ziehen ^.^ (wenn es sich um bilder handelt z.b).

kurzum es ist nahezu nicht möglich (u.U mit einem content management wie TYPO3?) ein copyright in die Bilder/videos einzusetzen wäre wohl die leichtere / billigere lösung.

LieberNetterFlo · 4. Mai 2010

beim Firefox zB brauchst nur "Extras -> Seiteninformationen -> Medien" klicken und schon hast ne Liste mit allen Bildern ... das kannst einfach net verhindern, da, wie mein vorposter gesagt hat, alles was er angezeigt bekommt beim User ist ...

Schwer zu überwinden ist nur Flash ... aber gegen die "Druck" Taste hilft das auch nicht

ScoutX · 4. Mai 2010

Eure bedenken kenne ich alle und übrigends mit Javascript weiß ich immer noch nicht wie ich in Mediawiki z.B. nur Bilddateien über Speichern unter blockieren kann.
Ich kenne die Skripte, kann aber beides nicht kombinieren.

Screenshot etc pp.: Er möchte dies nur etwas erschweren. Außerdem erzeugt so etwas weniger Bandbreitenlast (kein Extradownload, da entweder aus dem Cache entnommen oder Screenshot).
Es handelt sich um abfotografierte Werke seiner(!) eigenen Ölbilder.
Wie groß bzw. welche Auflösung die Dateien haben werden, kann ich nicht sagen.
Sollte Google aber irgendwann auf eines seiner Bilder stoßen, könnte (siehe oben) es an die Bandbreite gehen.

p.s. Er will kein Flash und ich will es auch nicht.

LieberNetterFlo · 4. Mai 2010

hach ja, da benutzt dann doch mal google für andere

Code:

<HTML><HEAD>
<script language="javascript">
 function click(e) {
  if (navigator.appName == 'Netscape'
           && e.which == 3) {
      alert("no right click please")
      return false;
      }
   else {
      if (navigator.appName == 'Microsoft Internet Explorer'
          && event.button==2)
         alert("no right click please")
         return false;
         }
   return true;
 }
document.onmousedown=click
</script>
</HEAD>
<BODY>
No right mouse button here!
</BODY></HTML>

oder/ und

Code:

<HEAD>
<SCRIPT LANGUAGE="JavaScript1.2">
var ns = (document.layers)? true:false;
var ie = (document.all)? true:false;
if (ns) document.captureEvents(Event.MOUSEDOWN || Event.CLICK);
document.onclick = sourcecodeprotect;
document.onmousedown = sourcecodeprotect;

// ***********************************************************
function sourcecodeprotect(e) {
  if (ns&&(e.which==3)) return false;
  else if (ie&&(window.event.button==2)) alert("Source code protected");
  else return true;
  }

//***********************************************************
function cleanup() {
  if (ns) document.releaseEvents(Event.MOUSEDOWN || Event.CLICK);
  }

</SCRIPT>
</HEAD>
<BODY onunload="cleanup()">
No right click here!
</BODY>

oder/ und
reicht meistens aus

Code:

<BODY oncontextmenu="return false">

dann gibts noch

"To disable the Disable Mouse Dragging (Highlighting) "

Code:

<BODY ondragstart="return false">

und "To disable the SELECT/COPY"

Code:

<BODY onselectstart="return false">

quelle: http://www.rgagnon.com/jsdetails/js-0061.html
gefunden mit: google.de

ScoutX · 4. Mai 2010

Die Skripte sind aber leider nicht mediawikifähig bzw. lassen diese z.T. den Editor crashen und sehe gerade, dass selbst http://www.webmasterworld.com/html/4086720.htm nicht mehr funktioniert.

LieberNetterFlo · 4. Mai 2010

die scripte sollten natürlich nur auf die seiten die der user sieht und nicht in den Admin-Bereich ... eventuell kannst du da getrennt ändern?

nur was ich rot makiert hab sollte aber nichts crashen, oder?

Fatal Error · 4. Mai 2010

Falls er es nicht will da er die Werke vielleicht später verkaufen will o.ä., dann könntest du auf den Werken die im Internet verfügbar sein sollen ein Wasserzeichen hinterlassen. LieberNetterFlo hat sonst schon die wichtigsten aufgezeigt.

Was heißt nicht mediawiki fähig? du schreibst den javascript code hoffentlich nicht einfach bei den Beiträgen rein? Der gehört unabhängig davon auf die Seite, mediawiki bindet sicher javascripts ein, da kannst dus doch einfach dazuschreiben

DjNDB · 4. Mai 2010

ScoutX schrieb:
Außerdem erzeugt so etwas weniger Bandbreitenlast (kein Extradownload, da entweder aus dem Cache entnommen oder Screenshot).
[...]
Sollte Google aber irgendwann auf eines seiner Bilder stoßen, könnte (siehe oben) es an die Bandbreite gehen.

"Speichern unter" lädt die Datei ebenfalls aus dem Cache. Das hat mein kurzer Test mit WebScarab zumindest für Firefox und Internet Explorer bestätigt, und es ist auch naheliegend, dass das so implementiert wird. Insofern bringt das keine Bandbreiteneinsparung.

Bezüglich Google kann er das Indexing blockieren mit der robots.txt und entsprechenden Meta Tags.
Allerdings ist auch hier der Nutzen fraglich. Zum einen sollte man davon ausgehen, dass er Bilder in's Internet stellt, damit sie von möglichst vielen gesehen werden. Ansonsten könnte er sie auch passwortgeschützt hosten und nur einzelnen zugänglich machen. Zum anderen sind die Thumbnails von Googles Bildersuche auf Google Servern gespeichert. Traffic entsteht also nicht durch die Suche, sonder nur wenn jemand die Seite auch besucht (und durch das gelegentliche Indexing).
Die Frage ist also, spielt es eine Rolle wie jemand die Seite gefunden hat?
Ist es nicht gerade bei Bildern förderlich wenn sie über die Google Bildersuche gefunden werden können, insbesondere falls diese eventuell verkauft werden sollen?

ScoutX · 4. Mai 2010

@DjNDB: Du hast schon recht. Es gibt immer ein pro und contra. Googles Indexing verhindern wollte ich auch aus diesem Grund nicht.
Wasserzeichen werden eh implementiert.
Meine eigentliche Intention war aber (siehe Post 1, Ausgangsfrage), ob die bekannten Skripts auch mit Mediawiki laufen und wenn wie.
Ob ich dies tatsächlich einsetze, bleibt dahingestellt.
Da es eine einmalige Geschichte sein wird, wollte ich zumindest Möglichkeiten bieten.
Irgendwie ist der Thread aus dem Ruder gelaufen, da hier auch Wikiunerfahrene gepostet haben und nicht die Probleme mit den Editoren, die auf Javaskript laufen, kennen.
Deswegen kann man nicht irgendwo etwas reinschreiben.

LieberNetterFlo · 4. Mai 2010

Du solltest das so regeln dass bei der Anzeige für den BESUCHER die Scripts ausgeführt werden und für die AUTOREN nicht .. das sollte doch bestimmt gehen, oder?

ScoutX · 4. Mai 2010

Sag mir wie? Ich weiß es doch nicht.

Savaron · 5. Mai 2010

Ob Wiki oder nicht, sowas ist höchst unprofessionell und erinnert an Script-Kiddies, die möglichst viel JavaScript auf ihrer Homepage haben wollen. Wenn er nicht will, dass man die Sachen kopiert, soll er meinetwegen dicke fette Wasserzeichen reinbauen, aber das mit dem Dateidownload erschweren solltet ihr schnellstmöglich vergessen.

NullPointer · 6. Mai 2010

Absolute Zustimmung, zumal das Kontextmenü nicht nur für "Speichern unter..." gut ist, sondern auch noch für andere Dinge (bei Firefox-Powerusern mit vielen Add-ons können das sehr viele Dinge sein!) und es unheimlich nervt, wenn Website-Entwickler meinen, dieses Menü behindern zu müssen.

ScoutX · 6. Mai 2010

Ich habe mich eh für Drupal umentschieden.
Aber irgendwelche Poweruser werden sicher nicht auf diese Seite kommen.
Es gibt solche und solche Seiten und wenn, wäre es mir auch gleichgültig.

Solche Kommentare wie von Nullpointer kann ich insofern nicht nachvollziehen.
Alles ist relativ.
Ich betone nochmals, mir ging es darum, ob dies funktioniert und wenn wie dies in der Wiki einzubinden ist. Praxiseinsatz war fraglich, da ich insbesondere nach Methoden gesucht habe, die Bandbreite zu schonen, was bei einer bilderreichen Webpage nicht so einfach ist.

DjNDB · 6. Mai 2010

ScoutX schrieb:
Praxiseinsatz war fraglich, da ich insbesondere nach Methoden gesucht habe, die Bandbreite zu schonen, was bei einer bilderreichen Webpage nicht so einfach ist.

Er könnte die Bilder auch bei http://imageshack.us/ hosten, oder gar bei Flickr, DeviantART oder ähnlichen Foto Communities.
Da braucht es nicht unbedingt ein eigenes Webprojekt. Natürlich nur wenn das für den Anwendungsfall passt, den wir ja nicht im Detail kennen.

Wikimedia: Dateidownload erschweren

Captain

Lt. Junior Grade

Cadet 4th Year

Fleet Admiral

Lt. Commander

Lieutenant

Rear Admiral

Captain

Rear Admiral

Captain

Rear Admiral

Lt. Junior Grade

Lt. Commander

Captain

Rear Admiral

Captain

Ensign

Lt. Commander

Captain

Lt. Commander

Ähnliche Themen