52North / IlwisCore

Integrated Land and Water Information System (ILWIS) is a remote sensing and GIS software. ILWIS Core is the functional center of ilwis4..
http://52north.org/communities/ilwis/
35 stars 13 forks source link

User names and passwords #41

Closed MartinSchouwenburg closed 10 years ago

MartinSchouwenburg commented 10 years ago

for the moment the url I (will) use to connect to a database is something like

ilwis:somedatabasetype://host:port/somedatabase?user=userX&password=secretY&ssl=true

fairly similar to jdbc. The problem here is the presence of username/password. Should it be part of the url of the resource or not? You of course need it in the connector but outside that? Is the same table accessed by userX and userY not the same resource? You can argue that indeed they are different resources but what happens in a shared data situation (e.g. catalog on a server system). How do we represent the same data-source but with different (ilwis)resources (because of username/password in the url) in a understandable way?

It is simpeler to remove the username/password from the query and pass them as properties. This way the resource remains the same but is has (potentially) extra data available. The only point here is that you can't rely on the toString() of the url to give you a full url (at least in connectors that need usernames/password).

Of course when username and password are not part of the url the system has to provide some way of getting them but that is the clients responsibility.

The resources are now stored in a internal memory database table that exists solely at runtime so username and passwords are lost when Ilwis exits. When the system is restarted you wont have (automatic) access to previous accessible resources. Also an interesting issue.

for the moment I will keep them in the url but that might change.

ridoo commented 10 years ago

There is no way a client (ilwis in this case acts as client) could figure out if a remote server supports authorization or authentication only directly. One could try out by sending un-authorized requests and guess from returned HTTP codes but that is by far not reliable and good practice.

If a server provides a data set with different authorized views for different users, Ilwis should support it as well and handle it as different data source.

Anyway, I agree with your thoughts and to leave U/P as part of the URL for now.

MartinSchouwenburg commented 10 years ago

All creation (well almost all of them) 'calls' (constructors, creates, prepare) for IlwisObjects/Connectors have now a PrepareOptions parameter. In this parameter you can store a.o. things like username/password. Of course at connector level you have handle the info in that parameter. This is better than pushing as part of the url as the combo ur/type is unique and different username/password would lead to different datasources which is silly. PrepareOptions can handle more than only username/password. Any format specific thing or otherwise parameters that do no fit in well can be passed through this mechanism