Hi Stefan, about anonymous access, the app can use a demo location that is generated on the fly using cloning a "template location". If i well remember, PyWPS does something like that.
But you need to be limit the number of available instance running … (has to be a configurable option), to avoid a server overload. how may anonymous users can test the app at the same time is up to the capabilities of your server. Cheers, Massimo. On Mar 9, 2014, at 4:37 PM, Blumentrath, Stefan <stefan.blumentr...@nina.no> wrote: > Hi, > > Some more user comments: When we installed RStudio server in our company, our > network administrator actually only agreed, because we could limit the > listening-addresses / the server was not available from the internet and only > accessible within the trusted company network. The same would likely be true > for a GRASS web-interface too. So like Massimo, I would guess that the > “trused-user” approach would be the most popular… > > In fact, the only use-case I can imagine for an anonymous web access to a > GRASS installation would be demonstration / marketing, that people can have a > closer look without installing. But that would require, that the web UI is > comparable to the desktop solution to give a comparable impression… Would be > anonymous www-access be possible at all? I mean, how would one exclude > concurrent use of a mapset, i.e. two anonymous users accessing the same > mapset at the same time? > > Cheers > Stefan > > From: grass-dev-boun...@lists.osgeo.org > [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of epi > Sent: 9. mars 2014 15:28 > To: Glynn Clements > Cc: grass-dev@lists.osgeo.org > Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI > > Glynn, > > I’aware that the "security risk handling" in a web app is a hard and hot > topic, hopefully a lot of project are working on this direction > Of course a web-ui for grass will be designed for registered users and not > for the anonymous www (password, registration and https can be implemented) > > The “web-shell” feature is obviously reserved to only “trusted users”. > without this assumption application like Rstudio or IPython notebook should > not exist. > > A multi user approach needs to be based IMHO on unix each user has to have > its own home and access to filesystem. If this is not enough the application > can be restricted to a chroot jail but this is not part of the UI > development (is more a sys admin choice) > > For the authorization protocol it can be implemented using PAM. (i guess is > what Rstudio is using) > WT has a mature authentication module > > http://www.webtoolkit.eu/wt/blog/2011/11/29/wt___jwt_3_2_0 > http://www.webtoolkit.eu/wt/blog/2013/08/07/security__wt_and_the_new_breach_vulnerability/ > > The potential user of a web ui for grass, need to be a trusted user in any > case and need to go trough a registration process where an admin as to > approve it. not anonymous users allowed. > > I guess the code behind the web-ui has to sanitize each text entry, will be > this enough ? > A "sanitize inspection" on all the “input” coming from the web-ui can be > performed and this will be part of the UI itself, not of the grass modules. > with the aim to avoid people doing something like .. http://xkcd.com/327/ > ;) > > > Massimo. > > > On Mar 8, 2014, at 11:42 AM, Glynn Clements <gl...@gclements.plus.com> wrote: > > > > Rashad M wrote: > > > My main concern would be security. > > You will need to thoroughly sanitise all inputs. You cannot rely upon > GRASS modules to do this, as e.g. most string handling uses fixed-size > buffers, so you need to explicitly limit the length of any arguments > to avoid the possibility of buffer overruns. > > I am not clear with this. maybe security and web apps are creating me a > confusion. > > If you do not understand the principles of secure programming, you > shouldn't attempt to write a web interface to GRASS. > > GRASS modules typically do not attempt to be secure against invalid > input. If you're providing access to "untrusted" users (users who > aren't supposed to have the full privileges of the account under which > the modules are executed), you will need to prevent invalid input from > reaching the modules. > > -- > Glynn Clements <gl...@gclements.plus.com> > _______________________________________________ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
