[Gvsig_english] WMS connection header
rndbrb at libero.it
rndbrb at libero.it
Tue Jul 17 12:02:59 CEST 2007
ok Jaume
Sorry for the errors in the previuos post and lets start from the beginning.
To understand the follwing cons keep in mind that:
A) HTTP is a stateless protocol;
B) Access to a WMS URL via GVSIg client is somewhat different then doing the same in a web browser (communication and, above all, the response has much more constraints).
C) the URL contained in the text below are only dummy url.
Suppose you have a WMS server (in previous post sometimes you found WFS instead of WMS, I was wrong, i meant the server exposes WMS service and the client shows WMS data) exposing a single .shp file land_cover(ID, type, surface) and say you have two kind of clients (two offices) accessing the server.
The first office has to process a subset of the attributes in the shape while the second migth be interested in others.
This might be the case, for example, when an office works on quanatitative aspects, like percent of land covered by trees (for
this clients only 'surface' should be the output), and the other office works on the dynamics of the types on the land (the
client in this case should show only the attribute 'type' of the shape).
The same WMS service (the same URL) should produce two different responses for personnel belonging to the two offices.
Another case where you might request a different response depending on the office (i.e the client ) is when the two offices
competences differ by geographic area. So when a clerk belonging to the office 'A' requests the url "http://www.myWms/" he doesn't have to worry about selecting the area he works on, the WMS server can do the job for him.
Still another case might be when you simply want to protect your spatial data and make it accessible only for some web users.
The goal till now is: one service, and hence one set of geographic data, many ways of using it (am I asking too much ??)
How can we make it possible via http ??
A simple solution could be a database of user profiles ( userP(name, Passw, Token, geoDataSet)) where you store
autorization/authentication infos.
Whenever a request to "http://www.myWms/" is made (the request is made by a gis client like GVSIG in 'add WMS layer' ) a
script, on the server side, searches the userP table to see if a good token (each token has a lifetime) exists for the user.
If the token is ok then the appropriate set of data will be processed and sent to the client.
The answer is how do we create the token (ticket) ? First of all we must connect with the browser to a normal page like an
authentication page "http://www.myWms/mylogin/". A form with username and password is sent from the cli to the server and if
the credentials are good two things must happen:
1) the server must produce a token for the user;
2) the server has to send the token to the cli as a cookie.
In this way all the requests to the url "http://www.myWms/" will have the token in the http header (cookie field of http
header) and te server will be able to know who is requesting the service.
The problem arises from the request (add WMS layer) incapsulated in gvsig software.
The header infos are cleared so no cookie arrives to the server. Hence when you add a WMS layer, the server cannot decide who is
the client and what kind of data must be returned.
Raimondo Barbieri
Progetto Podis
Regione Basilicata
Tel. 0971 575253
------------------------------------------------------
Leggi GRATIS le tue mail con il telefonino i-mode di Wind
http://i-mode.wind.it/
More information about the Gvsig_internacional
mailing list