AW: [Mapbender-users] Login & MeetingPoint

Tue Nov 7 10:13:18 EST 2006

Hallo,

> (GEO-Daten sind halt für alle da ;-)

Nicht ALLE Geo-Daten sind auch für ALLE Benutzer da. Es gibt dazwischen auch wenige Layer, die nicht jeder benutzen soll. Sonst bräuchte der Mapbender ja gar keine Benutzerverwaltung.
Bei uns wären das z.B.:
- ALK ([amtliche?] Autom. Liegenschaftskarte [-Auszüge drucken?])
- NKF (neues kommunales Finanzwesen, "Welches städt. Grundstück kostet wieviel?")

Geplant sind demnächt noch:
- ALB (Autom. Ligenschafts-Buchwerk)
  darin auch Eigentümer, d.h. Personen-Daten (Achtung Datenschutz!)
- Einwohnerwesen
  (Anbindung des Verfahrens "OK.EWO" an Mapbender)

Der Zugriff auf Einwohner-Daten durch nicht authorisierte Benutzer muss unbedingt verhindert werden! Die Anwendung wird sonst nicht von den Datenschützern genehmigt.

In manchen Installationen soll auch einfach nur protokolliert werden, wer welchen Ausdruck erzeugt hat (Abrechnung).

> Wie sollte denn z.Bsp. eine Autorisierung stattfinden, wenn 
> ein angemeldeter User per Mail den 'Meeting Point' an 
> jemanden verschickt, der gerade nicht angemeldet und ggf. für 
> diese GUI gar nicht autorisiert ist?

Wenn er/sie nicht für diese GUI autorisiert ist, wird das schon seinen Grund haben.
Ich gehe dann mal davon aus, dass er/sie die GUI auch nicht sehen soll.
Sonst muss der Admin eben die Autorisierung nachtragen.

Bei den Links mit BBOX aus Fachanwendungen heraus hatten wir die Richtlinie:

- Erst das Login durchlaufen bis zu einer Anwender-GUI.
- Dann konnte aus der Fachanwendung heraus 
     (z.B. ein Windows-Programm zur Erfassung der Grundstücks-Bewertung) 
  die GUI immer wieder auf ein neues Objekt 
     (hier ein ALB-Flurstück über Koordinate) 
  positioniert werden.

Das ist seit MB 2.4 nicht mehr möglich.
Wir möchten aber nicht die Mapbender-Passworte zusätzlich im NKF verwalten und im Kanalkataster und im Straßenkataster ....  und ... und ...

Darum folgende Diskussion: http://www.mapbender.org/index.php/Talk:MeetingPoint

Ich sehe vor allem auch die Gefahr, dass der Anwender gar nicht merkt, dass er gerade sein Passwort veröffentlicht.
Man muss dazu eine URL zerlegen und interpretieren können. Der Mapbender hat ja eine relativ breite Zielgruppe, nämlich alle, die kein Desktop-GIS haben. Da kann man solche Kenntnisse nicht von jedem erwarten.

Wenn nur &name + &pass eines Demo-Users verwendet werden, spricht nichts gegen dies Vorgehen. Das System kann aber mangels Kennzeichen keine Dummys von "echten" Usern unterscheiden.

Mein Vorschlag daher:  

* User und Passwort aus der generierten URL
    - weglassen (sicher ist sicher)
    - nur optional einfügen ("Ja, ich bin ein Dummy!")
    - von einem auszuwählenden Dummy-Demo-User verwenden (Würde ein neues DB-Feld zur Kennzeichnung voraussetzen)

* Eine URL ohne User und Passwort für bereits angemeldete Benutzer zulassen
  (das ist unabhängig von "MeetingPoint" für vielfältige Fachanwendungen die einzig saubere Lösung).

Gruß
F. Jäger     

> -----Ursprüngliche Nachricht-----
> Von: Ronald Woita [mailto:Ronald.Woita at rostock.de] 
> Gesendet: Dienstag, 7. November 2006 14:36
> An: users at mapbender.osgeo.org
> Betreff: Antw: [Mapbender-users] Login & MeetingPoint
> 
> Hallo Herr Jäger,
> 
> auf den ersten Blick stimme ich Ihnen zu, daß es bedenklich 
> ist Nutzer/passwort im Klartext in der URL mit zu übergeben.
> Wir nutzen Mapbender als Auskunftssystem sowohl im Intranet 
> als auch für jeden zugänglich im Internet.
> Selbst im Intranet nutzen nahezu 90%  (von ca. 400 
> regelmäßigen Usern) die Standard-GUI quasi ohne Anmeldung.
> (GEO-Daten sind halt für alle da ;-)
> Für diesen Nutzer sowie für den Internet-Besucher ist der 
> public 'dummy' völlig egal, da dieser hoffentlich eh nur 
> lesenden Zugriff auf die GUI hat.
> Um diesem Nutzerkreis, der sich selber ja nicht autorisiert, 
> die MeetingPoint Funktion zur Verfügung zu stellen,muß also 
> in der URL ein Nutzer mit übergeben werden.
> 
> Wie sollte denn z.Bsp. eine Autorisierung stattfinden, wenn 
> ein angemeldeter User per Mail den 'Meeting Point' an 
> jemanden verschickt, der gerade nicht angemeldet und ggf. für 
> diese GUI gar nicht autorisiert ist?
> 
> 
> mit freundlichen Grüßen
> 
> Ronald Woita
> 
> 
> 
> --
> Ronald Woita
> Hansestadt Rostock
> Kataster-, Vermessungs- und Liegenschaftsamt Holbeinplatz 14, 
> 18069 Rostock
> email: ronald.woita at rostock.de
> phone: +49 (0)381 - 381 6256
> 
> >>> F.Jaeger at KRZ.DE 07.11.2006 09:28 >>>
> ** DE **
> 
> Hallo Mapbenders,
> bis zur MB-Version 2.2.3 konnte man seinen Mapbender-Client 
> über den Parameter "Bounding-Box" (&mb_myBBOX=) sehr einfach 
> neu positionieren.
> 
> Wenn man bereits angemeldet war, brauchte man in der URL 
> keine Zugangsdaten übermitteln (User und Passwort). Wir haben 
> diese Funktion in Fachanwendungen eingebaut um eine 
> Verbindung von Fachdaten und GIS zu schaffen. Eine Koordinate 
> in den Fachdaten reicht dazu.
> 
> Seit Version 2.4 ist diese Verbindung nicht mehr benutzbar, 
> weil die überarbeitete login.php (so vermute ich) jetzt immer 
> die Parameter "&name=" und "&password=" verlangt.
> 
> Das ist aus meiner Sicht ein Rückschritt und 
> Datenschutzrechtlich bedenklich. Das Mapbender-Passwort 
> müsste in allen angebundenen Fachanwendungen gespeichert 
> werden. Diese Änderung haben wir nicht nachvollzogen.
> 
> Ich würde mir wünschen, dass die Änderung dieser 
> Verhaltensweise der BBOX-Funktion rückgängig gemacht wird.
> 
> 
> Meeting-Point
> 
> Ich habe mir die neue Funktion "Meeting Point" angesehen:
> 
> Hier ein Beispiel:
> http://wms1.ccgis.de/mapbender_dev/frames/login.php?name=demo&
password=demo&mb_user_myGui=meetingPoint&mb_myBBOX=3488740,5762404.389534884,3498810,5769605.610465116> &mb_myPOI=Komm_zum_KRZ,3494610,5766280 
> 
> Der Anwender kann damit selbst URLs mir den Parametern 
> "Bounding-Box" (&mb_myBBOX=) und "Point Of Interest" 
> (&mb_myPOI=) generieren. Beschreibung siehe: 
> http://www.mapbender.org/index.php/MeetingPoint
> Die URLs können dann z.B. als Email verschickt werden.
> 
> Zu meinem Erschrecken musste ich feststellen, dass in der 
> generierten URL auch Benutzerkennung und Passwort enthalten 
> sind. So ist die Funktion nach meiner Mainung nicht zu 
> gebrauchen. Man kann den Benutzer doch nicht veranlassen, 
> seine Zugangsdaten per Email zu verschicken. Er merkt es 
> möglicherweise gar nicht, wenn er den internen Aufbau der URL 
> nicht interpretieren kann.
> Da die login.php zur Zeit nicht ohne diese Parameter 
> funktioniert (s.o.), müssen sie aus formalen Gründen enthalten sein.
> Aus Datenschutzgünden ist die Funktion so aber in einer 
> produktiven Umgebung nicht benutztbar.
> 
> Das ist ein Grund mehr, die login.php so zu ändern, dass sie 
> auch ohne User und Passwort in der URL neu positioniert werden kann. 
> 
> 
> ** EN **
> 
> until MB 2.2.3 you could use the parameter "&mb_myBBOX=" in 
> an URL for positioning the GUI from an external application. 
> Before you have to log in once.
> 
> Since MB 2.4 you have to serve the parameters "&name=" and 
> "&password=" in every URL.
> Therefore you have to save User and Password in every 
> external Application. That's not save an no good practice.
> 
> The new function "Meeting-Point" (see links in DE) generates 
> URLs for BBOX and POI.
> But also "name" and "password" are part of this URL. The User 
> will send this as Email or put his password on a Website!
> 
> If "login.php" works without this parameters (as in 2.2.3) 
> this wouldn't be needed in "Meeting-Point".
> 
> 
> Mit freundlichen Grüßen
> Frank Jäger
> 
> KRZ
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at mapbender.osgeo.org
> For additional commands, e-mail: users-help at mapbender.osgeo.org 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at mapbender.osgeo.org
> For additional commands, e-mail: users-help at mapbender.osgeo.org
> 
> 