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