diltigug
Nachdem ich in meinem ersten Post hier im Forum noch in der Entscheidungsphase Dokuwiki ja oder nein war, hat mich inzwischen die Geschäftsführung überrascht, um nicht zu sagen überrollt. :-) Das Wiki soll jetzt kurzfristig umgesetzt werden.
Nun kommen doch noch einige Detailfragen auf. Der Übersichtligkeit halber werde ich die natürlich nach und nach jeweils in Einzeltreaths stellen.
Das Wiki soll jetzt doch auf unserem Webspace (bei externen Provider) eingerichtet werden, auf dem auch unsere öffentliche, extern betreute HP liegt, um unsere außerhalb tätigen Mitarbeiter mit einzubinden. Also wird das Thema Rechte und Zugangsberechtigungen ein großes Thema werden. Im Prinzip habe ich das soweit auch schon hinbekommen. Nur als "Webspace-Laie" habe ich jetzt mal eine Frage, die nur am Rande mit DW zu tun hat:
Ist es möglich, das auf dem öffentlichen Webspace liegende Wiki so zu konfigurieren, das Mitarbeiter, die an ihrem Arbeitsplatzrechner im Firmennetzwerk sitzen, das Wiki einsehen können ohne sich ins Wiki extra einloggen zu müssen? Also, wenn diese im Wiki nur was nachschauen und nichts editieren möchten.
Ich hoffe, ich habe mich verständlich ausgedrückt.
Aus zwei Gründen fände ich das gut:
1. natürlich, das man sich nicht jedesmal extra einloggen muß, nur wenn man den Inhalt nur einsehen will (wäre wohl noch im Browser durch abspeichern des Passworts lösbar).
2. das die vielen "Bearbeiten"-Button nicht angezeigt werden, wenn man den Inhalt nur einsehen will.
cziehr
Guten Morgen!
Du könntest das mit einem htaccess-Verzeichnisschutz realisieren. Da muss man einen Benutzernamen/Passwort eingeben, um überhaupt zur eigentlichen Seite zu gelangen. Wenn ihr in eurer Firma eine feste IP für den Internetanschluss habt, kann bei der htaccess-Datei angegeben werden, dass Anfragen die von dieser IP kommen keine Benutzerdaten eingeben müssen.
Nachteil: Jemand, der einen Artikel bearbeiten will, muss sich zweimal anmelden. Einmal bevor er überhaupt auf die Seite kommt, und dann nochmal im Wiki.
Viele Grüße,
Christoph
diltigug
Guten Morgen,
danke für das schnelle feedback.
Damit kann ich zumindest schonmal mit unserem Admin drüber reden.
Das zweimal Einloggen betrifft aber dann nur die externen Mitarbeiter, habe ich doch richtig verstanden, oder?
cziehr
Richtig, Mitarbeiter die aus dem Firmennetz kommen müssen sich nur zum Bearbeiten anmelden.
Das klappt aber wie gesagt nur, wenn ihr eine feste IP habt. Mit einem normalen DSL-Anschluss geht das nicht.
diltigug
Okay, verstanden.
Das mit der festen IP muß ich noch in Erfahrung bringen.
Danke
dinsdale
Hallo,
das Wiki kann in den Konfigurationseinstellungen so eingestellt werden, dass ohne Anmeldung diverse Buttons nicht angezeigt werden. Sprich also für den öffentlichen Nutzer, der nur lesen können soll.
Ganz habe ich die Logik noch nicht verstanden:
Das Wiki soll bei einem Hoster liegen, um Zugriff von ausserhalb zu erlangen. Es soll aber grundsätzlich nicht öffentlich sein. Dann wäre die .htaccess Idee wahrscheinlich am einfachsten, weil man so auch nicht bei Google etc. auftaucht. Ansonsten kann man das Wiki ja immer als Readonly konfigurieren, so dass nur bestimmte Benutzer editieren können.
Auf jeden Fall sollte SSL zum Einsatz kommen, da sonsten alle Passwörter etc. unverschlüsselt übers Netz gehen. Gerade, wenn man "aus Versehen" in einem unverschlüsselten WLAN Hotspot sitzt sind dann schnell mal Zugangsdaten abgefischt...
diltigug
dinsdale wrote
Das Wiki soll bei einem Hoster liegen, um Zugriff von ausserhalb zu erlangen. Es soll aber grundsätzlich nicht öffentlich sein.
Genau so.
dinsdale wrote ...weil man so auch nicht bei Google etc. auftaucht.
Der Hinweis ist gut, das wäre auf jeden Fall so gewünscht.
dinsdale wrote
Auf jeden Fall sollte SSL zum Einsatz kommen, da sonsten alle Passwörter etc. unverschlüsselt übers Netz gehen. Gerade, wenn man "aus Versehen" in einem unverschlüsselten WLAN Hotspot sitzt sind dann schnell mal Zugangsdaten abgefischt...
Auch ein wichtiger Hinweis. Danke.
Dazu gleich eine Frage vom Web-Laien: Um so eine Seite mit/über SSL zu betreiben, reicht es dazu das Wiki auf dem Webspace einfach nur in dem https-Ordner statt dem http-Ordner zu installieren, oder gehört da noch mehr dazu?
dinsdale
Auch ein wichtiger Hinweis. Danke.
Dazu gleich eine Frage vom Web-Laien: Um so eine Seite mit/über SSL zu betreiben, reicht es dazu das Wiki auf dem Webspace einfach nur in dem https-Ordner statt dem http-Ordner zu installieren, oder gehört da noch mehr dazu?
Das hängt davon ab, was der Hoster bereitstellt. Bei Goneo bspw. aktiviert man SSL für einzelne Domains, dann wird die Konfiguration für den Ordner, in dem dann bspw. das Wiki liegt, entsprechend angepasst. Auf jeden Fall muss der Hoster es unterstützen, sonst wird es nichts mit SSL, das kann man nur Serverseitig konfigurieren, was bei einem Sharehoster, wovon ich mal ausgehe, nicht möglich ist ( bzw. nur im Rahmen des Tarifs).
diltigug
Hallo,
es ist soweit, ich habe heute das DW auf einer subdomain installiert und habe als "Web-Anfänger" nun dazu noch Fragen, die wahrscheinlich nur am Rande mit DW zutun haben, aber vielleicht mag mir ja trotzdem jemand etwas Nachhilfe geben. ;-) Gern auch Tipps zu anderen Quellen oder Foren.
Das Wiki kann jetzt mit "subdomain.domain.de/dokuwiki" aufgerufen werden.
Was muß ich tun, damit ich das Unterverzeichnis (/dokuwiki) nicht mit angeben muß?
Das Wiki soll nur über https erreichbar sein. Ein entsprechendes Zertifikat liegt vor und die Seite ist auch schon entsprechend aufzurufen. Nur ist sie nach wie vor auch über http und ohne Angabe eines Protokolls erreichbar.
Was muß ich tun, das der Seitenaufruf immer über das https erfolgt, egal, wie man die Adresse eingibt?
Läuft das alles über eine htaccess-Datei? Oder muß evtl. providerseitig was konfiguriert werden?
Ich finde es gerade schwierig einen Einstieg in das Thema zu finden und wäre für Tipps dankbar.
P.S. Ach ja, den Passwortschutz per htaccess mag er auch noch nicht, aber das liegt wahrscheinlich am Provider (1&1).
dinsdale
Hallo,
also eine direkte Umleitung auf HTTPS kann man so erreichen ( in der .htaccess datei):
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
Beim einrichten der Subdomain sollte man eigentlich das passende Rootverzeichnis angeben können, also in deinem Falle "dokuwiki". So ist das zumindest bei Goneo gelöst. Da landet man dann bei subdomain.domain.de automatisch.
diltigug
Hallo,
prima, das mit dem https klappt schon mal.
Das mit dem Unterverzeichnis direkt bei der subdomain anzugeben muß ich mir noch anschauen, dazu brauch ich unseren webspace-Admin. :rolleyes:
Das Installieren direkt ins root-Verzeichnis ohne den /dokuwiki-Unterordner funktionierte nicht, weil der Server im Root kein Unterverzeichnis mit dem Namen lib zugelassen hat. Genauso, wie er einen Passwortschutz über htaccess nicht akzeptieren will.
diltigug
So, jetzt scheint fast alles so zu laufen, wie gewünscht. Nur ein paar Ungereimtheiten beobachten wir zur Zeit noch.
Kurzes feedback:
- Unser webspace liegt auf einer windows-Umgebung bei 1&1, d. h. wir mussten den Verzeichnisschutz über die Webspace-Administration einrichten, einen eigenen htpasswortschutz per htaccess und ftp können wir nicht einrichten. Ist bei denen so.
- die so erzeugte htaccess konnten wir dann allerding um die geünschten Funktionen erweitern (Umleiten auf https und den Unterordner der Wiki-Installtion, Ausnehmen der festen Büro-IP von der htaccess-Passwortabfrage)
Ungereimtheiten:
- Die Passwortabfrage ploppt zweimal auf, nach zweimaliger Eingabe läuft aber alles normal.
- Gestern war auf einmal unsere ergänzte htaccess mit der ursprünglich über die Webspace-Administration erzeugten Version überschrieben, als ob da providerseitig irgendwas zurückgesetzt wurde. Nach dem Einspielen unserer ergänzten htaccess funkt aber wieder alles. Das überschreiben oder löschen der falschen Datei funktionierte allerdings nicht direkt per ftp. Wir mussten die neue Datei erst in einen anderen Ordner hochladen und konnten diese dann online verschieben. Nur so ließ sich die falsche htaccess überschreiben.