[Mapbender_dev] User Story 1: Publishing a service

Tue Jun 8 03:42:49 EDT 2010

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) <seven at arnulf.us> 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 <
> > > arnulf.christl at metaspatial.net> 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
> > Mapbender_dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/mapbender_dev
> >
> > > -----------------------------------------------------------------------
> > >-
> > >
> > > _______________________________________________
> > > Mapbender_dev mailing list
> > > Mapbender_dev at lists.osgeo.org
> > > 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
> > Mapbender_dev at lists.osgeo.org
> > 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
armin.retterath at lvermgeo.rlp.de
http://www.geoportal.rlp.de