[Mapbender_dev] User Story 1: Publishing a service

Tue Jun 8 04:38:14 EDT 2010

Hi Armin,

Thanks for pointing this to me. I will go through it. There is no english
version of this page. but thanks to Google translate :-)

2010/6/8 Armin Retterath <armin.retterath at lvermgeo.rlp.de>

> 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
> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapbender_dev/attachments/20100608/8e997e16/attachment.html