hi vikas, the authentication should be done as a digest authentication. we have an authentication module to secure the registrated service as an ows proxy. the digest hashes for all users are already stored in the mapbender mb_user table since 2.7 (trunk) see http://www.mapbender.org/Http_auth
regards armin Am Montag 07 Juni 2010 21:36:28 schrieb Vikas Banjara: > Hi all, > > First of all, sorry for not attending the IRC meeting today. There was a > power cut in our city today. And the laptop battery was drained. > > Now coming to the progress of the project. I have started writing > authentication code. I will commit the code after I have done with the > authentication module. > > Discussion about the use case inline - > > On Fri, Jun 4, 2010 at 6:37 PM, Seven (aka Arnulf) <[email protected]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Vikas Banjara wrote: > > > Hi all, > > > > > > I will try to write a flow of steps for the use case. Please correct me > > > wherever I am wrong. > > > > Hi Vikas, > > I will answer inline and as approprite update the Wiki in parallel. It > > was suggested that we need to be more wordy when describing the user > > stories. What is your opinion? Can you understand what the user wants to > > do? Would a more detailed description help to understand better? > > > > One important thing I did not mention yet is that we should always keep > > in mind that the "user" we are talking about can also be a "user agent". > > This means it can well be a machine! This is important to keep in mind. > > Especially the more complex issues regarding monitoring, usage of RSS > > and anything that can be automized will be highly relevant for machine > > to machine communication. > > Yeah, user stories and the following discussion should be as wordy as > possible. Also, I am keeping in mind the fact that "user" will actually be > a machine. And we are writing code for machine-machine interaction. > I will take care of RSS usage. > > > More answers to your questions inline. All cases that I do not comment I > > assume that we are thinking along the same lines. > > > > > On Tue, Jun 1, 2010 at 10:26 PM, Arnulf Christl < > > > [email protected]> wrote: > > > > > > Hi Vikash, > > > here goes the first try for a user story: > > > > > > User finds a new service / creates a new service and wants to publish > > > it. All that is needed to register a new service is a user name > > > (authentication) with email for confirmation, the Capabilities URL of > > > the service and whether it should be public. > > > > > >> First the user needs to authenticate himself using a > > >> username/password. > > > > For > > > > >> this I am working on plain http authentication with the mapbender > > > > server. > > > > For a start that is OK. Later we might want to look into how we can make > > the authentication more persistant (see also: user agent / machine > > scenario). > > What do you mean by user agent/machine scenario authentication? IP based > authentication? > > > >> The registering of a new service is a Create operation. So, it should > > >> be > > > > a > > > > >> POST operation. And the URI should be like this (assuming that the > > >> url > > > > of > > > > >> the mapbender server is www.mapbender.org) - > > >> http://www.mapbender.org/resources/resourceID > > >> > > >> So to post this user would send four parameters username, email id and > > >> capabilities url and public/private status of the service. > > > > > > Q: What happens if this URL (or a similar one?) has already been > > > uploaded earlier? Add a counter for the the same URL (uploaded several > > > times)? > > > A: The Capabilities URL needs to be checked against the ones already in > > > the database. -> What happens then? > > > > > >> In case, the capabilities URL already exists, we can send an error to > > > > the > > > > >> user saying that it already exists. > > > > The response (artefact: "Representation returned to the client") should > > include option of how to continue processing. That could be the link to > > the existing resource and maybe one to the "Update" REST interface. > > Point noted. > > > > Q: What happens if the user gets "lost", is deleted, etc.? > > > A: ? > > > > A user can be deleted from the Mapbender database. What happens to the > > "owner" of the resource in that case? We could trigger an SQL cascade > > DELETE on the database but in my opinion it would be nicer to keep > > resource URL even if the owner disappears. We could introduce a garbage > > or public user for those cases but then must take care that we do not > > get mixed up with permissions and the security proxy. > > I guess this is not really a part of api. This is a part of mapbender core > feature. Am I correct? > > > >> I didn't really get this? > > > > > > Q: What happens if the service is deleted by another user? (This is > > > currently not possible, it would generate an error message). > > > > > > > > > > > > > > > Q: What happens if Mapbender cannot read the capabilities document? > > > A: Error message & ? > > > > > >> Again can you explain me this? > > > > An example might help: > > This URL delivers an OGC WMS Capabilities Document that Mapbender can > > parse and store in the database: > > http://demowms.fossgis.de/wms/simple?SERVICE=WMS&REQUEST=GetCapabilities > > (even although the URL misses the parameter VERSION=x.x.x) > > > > This URL on the other hand does not deliver an OGC WMS Capabilities > > Document that Mapbender can parse: > > http://gdz.bkg.bund.de/wms_dtk25&v_service=wms&response_xml=wms_dtk25 > > > > In my opinion it (should) return a 401 or 403 but instead sends a 200 > > (OK) and then says in the XML that it returns that it is not OK. We will > > have lots of confusing response codes but should therefore still not > > ignore them but make as best use of them as we can. > > > > Find more examples of working OGC WMS URLs from this page: > > http://www.mapbender.org/Test > > > > > > Please add to this list when you find an interesting or "strange" OGC > > service. > > I will compile a list of response codes in the wiki page. > > > > Q: Are we going to use this "interface" also to update services or do > > > we need to create another one? > > > A: ? > > > > > >> To update the service we need to create a separate interface. And that > > > > would > > > > >> be using PUT HTTP command. > > > > Yes. This "interface" (or is it not rather a resource too?) should be > > included in the response to a request that wants to create a resource > > that already exists. > > Yeah, as you mentioned above also. > > > Best regads, > > Arnulf > > So, if everything is ok. I will write a set of conclusions for this > discussion in my next mail and will also compile it in the wiki page. And > then we can start with next user story. > > Regards > Vikas > > > > We add these User Stories to the Wiki so that we can refine them there: > > > http://www.mapbender.org/Talk:RESTful_API > > > > > > > > > Best regads, > > > Arnulf. > > > > _______________________________________________ > > Mapbender_dev mailing list > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/mapbender_dev > > > > > ----------------------------------------------------------------------- > > >- > > > > > > _______________________________________________ > > > Mapbender_dev mailing list > > > [email protected] > > > http://lists.osgeo.org/mailman/listinfo/mapbender_dev > > > > - -- > > Arnulf Christl > > > > Exploring Space, Time and Mind > > http://arnulf.us > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iEYEARECAAYFAkwI+pgACgkQXmFKW+BJ1b1f/QCdHo3nhNjsyHz5zL7NTex4V0Of > > EpYAmwT9+AN+PRg1maCj82wRaZvSqUPj > > =x4Hb > > -----END PGP SIGNATURE----- > > _______________________________________________ > > Mapbender_dev mailing list > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/mapbender_dev -- Im Auftrag -- Armin Retterath Kompetenz- und Geschäftsstelle Geodateninfrastruktur Rheinland-Pfalz beim Landesamt für Vermessung und Geobasisinformation Rheinland-Pfalz Ferdinand-Sauerbruch-Straße 15 56073 Koblenz Telefon 0261/492-466 Telefax 0261/492-492 [email protected] http://www.geoportal.rlp.de _______________________________________________ Mapbender_dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapbender_dev
