Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
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
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Stefan, On Mon, Mar 10, 2014 at 7:00 AM, epi massimodisa...@gmail.com wrote: 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. This is more of a customization of webGRASS. WebGRASS UI is the web extestion to run grass modules. If you want to allow anonymous users or trusted users is a question of deployment. Some webmapping framework allows a demo users and the person who installs webgrass on their server be it on internet or else, he must know his users as any other typical web application. For example you can deploy your data on internet using web services and map viewer client like OpenLayers and allow anonymous users or setup a login and allow only verified users. Again the the login could use (OAuth, simple db login, manual verification, auto email verification etc.). This shouldn't be a part of web framework in my opinon. Rather web application allows such provision in a non coupled way. In case of webgrass we decide to have trusted login by default. 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.orggrass-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
Re: [GRASS-dev] [GRASS GIS] #2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr --+- Reporter: mlennert | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: r.in.gdal, v.in.ogr, gui |Platform: Unspecified Cpu: Unspecified | --+- Comment(by mlennert): I would like to revive this discussion. Recently, I imported a vector file with the wxgui import wizard. I got a message that there were a series of errors and a hint to try to set a specific snapping distance. However, in the wizard there is no way to set the snap parameter and there is no way to get from the wizard to the actual module. You have to be an informed user to know that you have to launch the module from the terminal, or with the --ui option. Again, I plead very strongly for not dumbing down the GUI too much and for leaving passages to power-user approaches. Even if such passages might confuse some newbie users (although I would like to see some stats on how often this really happens), I think that the improvement in ease of use for other users and the pedagogical effect of showing these advanced approaches instead of hiding them are worth the occasional confusion. Moritz -- Ticket URL: https://trac.osgeo.org/grass/ticket/2042#comment:17 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] (standalone/OSGeo4W)Wingrass-R-integration - which way to go?
Hi Massimo,
That will be great!
we do need grass able to talk with R also in osgeo4w.
unlike as rpy2 are R-python-bindings, the R-batchfiles simply enables
invoking R from anywhere you are, e.g. within a WinGRASS-session or within a
OSGeo4W-shell/commandline:
echo The script is self contained so just place it anywhere on your Windows
echo PATH. (From the Windows cmd line the command PATH shows your current
echo Windows path.) You may optionally make copies of this script with
names
echo like R.bat, Rscript.bat, Rcmd.bat so that each has a different default.
some ideas behind the R-batchfiles:
__
echo (c) 2013 G. Grothendieck
echo License: GPL 2.0 ( http://www.gnu.org/licenses/gpl-2.0.html )
echo Launch script for R and associated functions.
echo Usage: R.bat [subcommand] [arguments]
echo Subcommands where (0) means takes no arguments; (A) means may need
Admin priv
echo cd - cd to R_ROOT, typically to C:\Program Files\R (0)
echo cmd - Run Rcmd.exe
echo dir - List contents of R_ROOT in chronological order showing R
versions (0)
echo gui - Run Rgui.exe
echo help - Help info (0)
echo path - Add R_TOOLS, R_MIKTEX ^ R_PATH to path for this cmd line
session (0)
echo R - Run R.exe (0)
echo script - Run Rscript.exe
echo show - Show R_ variable values used. R_PATH, etc. (0)
echo SetReg - Run RSetReg; see 2.17 in R FAQ for Windows (A)
echo tools - Add R_TOOLS and R_MIKTEX to path for this cmd line session
(0)
echo touch - Change date on R_HOME to now (0) (A)
echo Examples
echo R -- invoke R.exeR gui -- invoke Rgui.exe
echo R dir -- show R versions R show -- show R_ variables
echo R CMD build mypkg -- builds mypkg
echo cmd /c set R_VER=R-2.14.0 ^ R gui -- run indicated Rgui version
echo cmd /c set R_ARCH=32 ^^^ R gui -- run 32 bit Rgui
echo cmd /c R_VER=R-2.14.0 ^^^ R setreg - make 2.14.0 current in registry
echo cmd /c R_VER=R-2.14.0 ^^^ R.bat touch - change date on R-2.14.0 dir
to now
[...]
__
some examples from within the download folder here on my laptop
__
C:\dl\batchfiles_0.7-1R
R version 3.0.3 (2014-03-06) -- Warm Puppy
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)
R ist freie Software und kommt OHNE JEGLICHE GARANTIE.
Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten.
Tippen Sie 'license()' or 'licence()' für Details dazu.
R ist ein Gemeinschaftsprojekt mit vielen Beitragenden.
Tippen Sie 'contributors()' für mehr Information und 'citation()',
um zu erfahren, wie R oder R packages in Publikationen zitiert werden
können.
Tippen Sie 'demo()' für einige Demos, 'help()' für on-line Hilfe, oder
'help.start()' für eine HTML Browserschnittstelle zur Hilfe.
Tippen Sie 'q()', um R zu verlassen.
q()
Workspace sichern? [y/n/c]: n
C:\dl\batchfiles_0.7-1
__
C:\dl\batchfiles_0.7-1R show
R_ARCH=x64
R_CMD=RShow
R_HOME=C:\Program Files\R\R-3.0.3
R_PATH=C:\Program Files\R\R-3.0.3\bin\x64
R_REGISTRY=1
R_ROOT=C:\Program Files\R
R_TOOLS_PATH={app}=
R_VER=R-3.0.3
__
C:\dl\batchfiles_0.7-1R dir
Volume in Laufwerk C: hat keine Bezeichnung.
Volumeseriennummer: 1490-7862
Verzeichnis von C:\Program Files\R
08.03.2014 22:15DIR ..
08.03.2014 22:15DIR .
08.03.2014 22:17DIR R-3.0.3
__
do you have any experience in running rpy2 on windows and within the system
python or with osgeo4w python ?
I've never had a closer look at rpy2 on windows. is a ready to use rpy2
available for windows.
-
best regards
Helmut
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/standalone-OSGeo4W-Wingrass-R-integration-which-way-to-go-tp5127931p5128030.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2211: g.gui.iclass raise a PyAssertionError
#2211: g.gui.iclass raise a PyAssertionError
--+-
Reporter: zarch| Owner: grass-dev@…
Type: defect | Status: closed
Priority: normal | Milestone: 7.0.0
Component: Display | Version: svn-trunk
Resolution: fixed|Keywords: g.gui.iclass, wxPython 3
Platform: Unspecified | Cpu: Unspecified
--+-
Changes (by zarch):
* status: new = closed
* resolution: = fixed
Comment:
Replying to [comment:1 annakrat]:
I fixed it hopefully in r59207.
Yes, now it works fine, thanks!
Please mention next time that you use wxPython 3, as a keyword for
example.
Sorry about that, you are right, I forgot to mention this important point!
Sometime I have some warning like GRASS is using deprecating methods,
should I report this warning somewhere, are you using wxPython3 too?
for example at the moment if I run g.gui.iclass I got:
{{{
G70 edi/pietro g.gui.iclass
/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64-unknown-linux-
gnu/scripts/g.gui.iclass:101: wxPyDeprecationWarning: Using deprecated
class PySimpleApp.
app = wx.PySimpleApp()
}}}
Let me know If I should report this kind of things somewhere, best regards
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2211#comment:2
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2210: unable to start GRASS GIS 7
#2210: unable to start GRASS GIS 7
-+--
Reporter: turek | Owner: grass-dev@…
Type: defect | Status: reopened
Priority: normal | Milestone: 7.0.0
Component: Python | Version: svn-trunk
Resolution: |Keywords:
Platform: Linux | Cpu: x86-64
-+--
Comment(by turek):
Hi,
I still get the same error. Maybe I am doing something wrong however
r59162 works for me:
{{{
ostepok@ostepok-pc:~/Dev/GRASS/grass_wms/grass_trunk/lib/init$ svn up
grass.py
Updating 'grass.py':
Ugrass.py
Updated to revision 59220.
ostepok@ostepok-pc:~/Dev/GRASS/grass_wms/grass_trunk/lib/init$ make
rm -f /home/ostepok/Dev/GRASS/grass_wms/grass_trunk/bin.x86_64-unknown-
linux-gnu/grass70
sed \
-e
's#@GISBASE@#/home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64
-unknown-linux-gnu#' \
-e 's#@GRASS_VERSION_NUMBER@#7.0.svn#' \
-e 's#@LD_LIBRARY_PATH_VAR@#LD_LIBRARY_PATH#' \
-e 's#@START_UP@#grass70#' \
-e 's#@CONFIG_PROJSHARE@#/usr/share/proj/#' \
grass.py
/home/ostepok/Dev/GRASS/grass_wms/grass_trunk/bin.x86_64-unknown-linux-
gnu/grass70
chmod +x /home/ostepok/Dev/GRASS/grass_wms/grass_trunk/bin.x86_64-unknown-
linux-gnu/grass70
rm -f /home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64-unknown-
linux-gnu/grass70.tmp
sed \
-e 's#@GRASS_VERSION_NUMBER@#7.0.svn#' \
-e 's#@START_UP@#grass70#' \
-e 's#@GRASS_CONFIG_DIR@##' \
-e 's#@LD_LIBRARY_PATH_VAR@#LD_LIBRARY_PATH#' \
-e 's#@CONFIG_PROJSHARE@#/usr/share/proj/#' \
grass.py
/home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64-unknown-linux-
gnu/grass70.tmp
ostepok@ostepok-pc:~/Dev/GRASS/grass_wms/grass_trunk/lib/init$
../../bin.x86_64-unknown-linux-gnu/grass70
Cleaning up temporary files...
Starting GRASS GIS...
Traceback (most recent call last):
File /home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64-unknown-
linux-gnu/etc/gui/wxpython/gis_set.py, line 37, in module
from core.utils import _
File /home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64-unknown-
linux-gnu/etc/gui/wxpython/core/utils.py, line 42, in module
from core.gcmd import RunCommand
File /home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64-unknown-
linux-gnu/etc/gui/wxpython/core/gcmd.py, line 744, in module
_enc = GetDefaultEncoding() # define as global variable
File /home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64-unknown-
linux-gnu/etc/gui/wxpython/core/gcmd.py, line 737, in GetDefaultEncoding
enc = locale.getdefaultlocale()[1]
File /usr/lib/python2.7/locale.py, line 511, in getdefaultlocale
return _parse_localename(localename)
File /usr/lib/python2.7/locale.py, line 443, in _parse_localename
raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: None
Error in GUI startup. If necessary, please report this error to the GRASS
developers.
Switching to text mode now.
Hit RETURN to continue...
Unable to create temporary directory /tmp/grass7-ostepok-7579! Exiting.
ostepok@ostepok-pc:~/Dev/GRASS/grass_wms/grass_trunk/lib/init$ svn up -r
59162 grass.py
Updating 'grass.py':
Ugrass.py
Updated to revision 59162.
ostepok@ostepok-pc:~/Dev/GRASS/grass_wms/grass_trunk/lib/init$ make
rm -f /home/ostepok/Dev/GRASS/grass_wms/grass_trunk/bin.x86_64-unknown-
linux-gnu/grass70
sed \
-e
's#@GISBASE@#/home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64
-unknown-linux-gnu#' \
-e 's#@GRASS_VERSION_NUMBER@#7.0.svn#' \
-e 's#@LD_LIBRARY_PATH_VAR@#LD_LIBRARY_PATH#' \
-e 's#@START_UP@#grass70#' \
-e 's#@CONFIG_PROJSHARE@#/usr/share/proj/#' \
grass.py
/home/ostepok/Dev/GRASS/grass_wms/grass_trunk/bin.x86_64-unknown-linux-
gnu/grass70
chmod +x /home/ostepok/Dev/GRASS/grass_wms/grass_trunk/bin.x86_64-unknown-
linux-gnu/grass70
rm -f /home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64-unknown-
linux-gnu/grass70.tmp
sed \
-e 's#@GRASS_VERSION_NUMBER@#7.0.svn#' \
-e 's#@START_UP@#grass70#' \
-e 's#@GRASS_CONFIG_DIR@##' \
-e 's#@LD_LIBRARY_PATH_VAR@#LD_LIBRARY_PATH#' \
-e 's#@CONFIG_PROJSHARE@#/usr/share/proj/#' \
grass.py
/home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64-unknown-linux-
gnu/grass70.tmp
ostepok@ostepok-pc:~/Dev/GRASS/grass_wms/grass_trunk/lib/init$
../../bin.x86_64-unknown-linux-gnu/grass70
Cleaning up temporary files...
Starting GRASS GIS...
Failed to set LC_ALL to None.UTF-8 (unsupported locale setting)
__ ___ _____
/ / __ \/ | / ___/ ___/ /
Re: [GRASS-dev] [GRASS GIS] #2211: g.gui.iclass raise a PyAssertionError
#2211: g.gui.iclass raise a PyAssertionError
--+-
Reporter: zarch| Owner: grass-dev@…
Type: defect | Status: closed
Priority: normal | Milestone: 7.0.0
Component: Display | Version: svn-trunk
Resolution: fixed|Keywords: g.gui.iclass, wxPython 3
Platform: Unspecified | Cpu: Unspecified
--+-
Comment(by annakrat):
Replying to [comment:2 zarch]:
Replying to [comment:1 annakrat]:
I fixed it hopefully in r59207.
Yes, now it works fine, thanks!
Please mention next time that you use wxPython 3, as a keyword for
example.
Sorry about that, you are right, I forgot to mention this important
point!
Sometime I have some warning like GRASS is using deprecating methods,
should I report this warning somewhere, are you using wxPython3 too?
I am not using yet, but I have some 2.9 version on my computer so I can
test it at least.
for example at the moment if I run g.gui.iclass I got:
{{{
G70 edi/pietro g.gui.iclass
/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64-unknown-linux-
gnu/scripts/g.gui.iclass:101: wxPyDeprecationWarning: Using deprecated
class PySimpleApp.
app = wx.PySimpleApp()
}}}
I fixed this one in r59221.
Let me know If I should report this kind of things somewhere, best
regards
yes, it would be good. There is already a ticket on some deprecation
warning as far as I remember but I am not able to find it now
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2211#comment:3
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] G7: how to extract nodes from vector map?
Hi, I try to extract nodes from a vector grid in GRASS 7. The idea is to extract pixel corners as vector points but it fails for me: Sample routine # NC 7, http://grass.osgeo.org/download/sample-data/ -- GRASS 7 full data g.region n=222800 s=222740 w=642590 e=642670 nsres=10 ewres=10 -p d.mon wx0 sleep 5 # otherwise wx0 will not show anything... d.rast aspect # generate a vector area map: r.to.vect input=aspect output=aspect_grid type=area d.vect aspect_grid # Now we have the vector grid map, how to extract the nodes of the intersections? v.to.points input=aspect_grid output=aspect_grid_nodes use=node # verify d.rast aspect d.vect aspect_grid_nodes col=red ## -- No, v.to.points extracts the centroids! v.to.points input=aspect_grid output=aspect_grid_nodes use=node type=boundary --o ## -- No: v.to.points complete. 0 points written to output vector map. ... no idea. Note: The d.vect command uses: Vect_get_node_coor(Map, el, X, Y, NULL); which are the desired grid nodes (boundary intersections). How to extract the nodes as a new map (in a not overcomplicated way)? thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
epi wrote: 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/ ;) That's the main thing. If you allow the user to e.g. provide names for maps, such names should be limited to alphanumeric characters and limited to a reasonable length. If you allow the user to provide a list of inputs, limit both the maximum number of items and the total length of the resulting textual representation. And so on. In short, GRASS modules are designed for use by local users who already have shell access, so there hasn't been any need to program defensively. The OS prevents people from e.g. reading or writing files which they aren't supposed to. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G7: how to extract nodes from vector map?
Hi, 2014-03-10 18:16 GMT+01:00 Martin Landa landa.mar...@gmail.com: that's because the module skips features without category [1], so `layer=-1` is your friend. I would say that current behaviour is very confusing even for power user... I added in r59226 warning about that, eg. WARNING: 106 features without category in layer 1 skipped. Note that features without category (usually boundaries) are not skipped when 'llayer=-1' is given. Also note that you need to enter `d.vect layer=-1` to show such points... Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G7: how to extract nodes from vector map?
Hi, 2014-03-10 16:55 GMT+01:00 Markus Neteler nete...@osgeo.org: v.to.points input=aspect_grid output=aspect_grid_nodes use=node type=boundary --o ## -- No: v.to.points complete. 0 points written to output vector map. ... no idea. that's because the module skips features without category [1], so `layer=-1` is your friend. I would say that current behaviour is very confusing even for power user... Or `type=area use=vertex` + `v.clean tool=rmdupl` Martin [1] http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.to.points/main.c#L205 -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G7: how to extract nodes from vector map?
On Mon, Mar 10, 2014 at 6:16 PM, Martin Landa landa.mar...@gmail.com wrote: 2014-03-10 16:55 GMT+01:00 Markus Neteler nete...@osgeo.org: v.to.points input=aspect_grid output=aspect_grid_nodes use=node type=boundary --o ## -- No: v.to.points complete. 0 points written to output vector map. ... no idea. that's because the module skips features without category [1], so `layer=-1` is your friend. I would say that current behaviour is very confusing even for power user... thank for the new warning in the code. Or `type=area use=vertex` + `v.clean tool=rmdupl` Honestly, still not that obvious... I first searched in v.extract, perhaps have a new flag there to allow that when type=point the extraction can be set to nodes or vertices? Markus [1] http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.to.points/main.c#L205 -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] (standalone/OSGeo4W)Wingrass-R-integration - which way to go?
hi, That will be great! we do need grass able to talk with R also in osgeo4w. ok, I've testet a stripped down R-batch-file http://osgeo-org.1560.x6.nabble.com/file/n5128182/setR.bat and put it into C:\OSGeo4W\etc\ini results: - R (R and RGui) starts in 'OSGeo4W Shell' and 'OSGeo4W' (OSGeo4W command shell) - OSGeo4W-WinGRASS6.4.svn/6dev-wxGUI starts without any problem - OSGeo4W-WinGRASS6.4.svn/6dev in text mode starts without any problem, R and RGui is usable within the GRASS session but - OSGeo4W-WinGRASS7.svn-wxgui doesn't start - OSGeo4W-WinGRASS7.svn in text mode doesn't start any testing/ideas are welcome to push this forward and propose it for including in OSGeo4W upstream. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/standalone-OSGeo4W-Wingrass-R-integration-which-way-to-go-tp5127931p5128182.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] FOSS4G 2014 workshop?
Hi all, is anyone planning to go to Portland in September for FOSS4G? Any plans for GRASS workshop? I am asking because the workshop proposal deadline is March 15. Vaclav and I are willing to do a workshop, probably on spatio-temporal data handling and visualization in GRASS. It would be good to coordinate our efforts if someone has similar plans... Anna https://2014.foss4g.org/calls-for-papers/workshop-proposals/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] FOSS4G 2014 workshop?
On Mon, Mar 10, 2014 at 9:34 PM, Anna Petrášová kratocha...@gmail.com wrote: Hi all, is anyone planning to go to Portland in September for FOSS4G? Any plans for GRASS workshop? I am asking because the workshop proposal deadline is March 15. Vaclav and I are willing to do a workshop, probably on spatio-temporal data handling and visualization in GRASS. It would be good to coordinate our efforts if someone has similar plans... I plan to go and would be happy to join efforts. Markus Anna https://2014.foss4g.org/calls-for-papers/workshop-proposals/ ___ 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
[GRASS-dev] [GRASS GIS] #2214: animator fails to render a second time
#2214: animator fails to render a second time -+-- Reporter: bhlevca | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: unspecified Keywords: |Platform: Linux Cpu: x86-64 | -+-- The animator works if it is used only once. It one tries to use it a second time the rendering will fail. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2214 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2214: animator fails to render a second time
#2214: animator fails to render a second time -+-- Reporter: bhlevca | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: unspecified Keywords: |Platform: Linux Cpu: x86-64 | -+-- Comment(by bhlevca): Replying to [ticket:2214 bhlevca]: The animator works if it is used only once. It one tries to use it a second time the rendering will fail. Forgot to mention that GRASS needs to be closed and restarted in order to make the animator work again. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2214#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2214: animator fails to render a second time
#2214: animator fails to render a second time -+-- Reporter: bhlevca | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: unspecified Keywords: |Platform: Linux Cpu: x86-64 | -+-- Comment(by annakrat): Are you talking about Animation Tool (command g.gui.animation)? Please be more specific how to reproduce the error, what does it mean second time? Replying to [comment:1 bhlevca]: Replying to [ticket:2214 bhlevca]: The animator works if it is used only once. It one tries to use it a second time the rendering will fail. Forgot to mention that GRASS needs to be closed and restarted in order to make the animator work again. I doubt that. Restarting Animation Tool should be sufficient for whatever error is there. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2214#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2214: animator fails to render a second time
#2214: animator fails to render a second time -+-- Reporter: bhlevca | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: unspecified Keywords: |Platform: Linux Cpu: x86-64 | -+-- Comment(by bhlevca): I am using g.gui.animation from the File- Animation tool. Second time means that if I want to create another animation without closing the tool and the whole GRASS environment. It works if I modify the existing animation ( parameters, add delete maps), but if fails for example if I set a new region. I tried to restart the animation tool but I get Fail rendering even if I start a new animation -- Ticket URL: http://trac.osgeo.org/grass/ticket/2214#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2214: animator fails to render a second time
#2214: animator fails to render a second time -+-- Reporter: bhlevca | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: unspecified Keywords: |Platform: Linux Cpu: x86-64 | -+-- Comment(by annakrat): Replying to [comment:3 bhlevca]: I am using g.gui.animation from the File- Animation tool. Second time means that if I want to create another animation without closing the tool and the whole GRASS environment. It works if I modify the existing animation ( parameters, add delete maps), but if fails for example if I set a new region. when I set new region and press rerender in the animation tool, I see the animation in the part specified by the region. Probably you have to write down detailed steps of what leads to error so that I can reproduce it. I tried to restart the animation tool but I get Fail rendering even if I start a new animation -- Ticket URL: http://trac.osgeo.org/grass/ticket/2214#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2214: animator fails to render a second time
#2214: animator fails to render a second time
-+--
Reporter: bhlevca | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI| Version: unspecified
Keywords: |Platform: Linux
Cpu: x86-64 |
-+--
Comment(by bhlevca):
Replying to [comment:4 annakrat]:
I tried to replicate and I could not crash it anymore. I guess we'll have
to close this until I find what was I doing, because I was not dreaming
when I reported this.
Meanwhile I found that I cannot render two animations. I am using multiple
raster files and not space time raster I am unable to have two animation
in the list and render both. When I am trying to render the second one I
am getting :
{{{
Inconsistent number of maps, please check input data.
}}}
looking in the code I see that only one animation is allowed in non-
temporal mode. Any reason for that? Thanks
{{{
if temporalMode == TemporalMode.NONTEMPORAL:
if len(mapCount) 1:
raise GException(_(Inconsistent number of maps, please
check input data.))
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2214#comment:5
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Glynn, I understood the risk and I agree in toto with you. For the web-ui interface we can define the rules for each kind of entry and publish the rules/restriction on a help page . Then when an invalid input exception is raised the ui will point the user to read the rules page. Massimo. On Mar 10, 2014, at 12:02 PM, Glynn Clements gl...@gclements.plus.com wrote: epi wrote: 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/ ;) That's the main thing. If you allow the user to e.g. provide names for maps, such names should be limited to alphanumeric characters and limited to a reasonable length. If you allow the user to provide a list of inputs, limit both the maximum number of items and the total length of the resulting textual representation. And so on. In short, GRASS modules are designed for use by local users who already have shell access, so there hasn't been any need to program defensively. The OS prevents people from e.g. reading or writing files which they aren't supposed to. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2214: animator fails to render a second time
#2214: animator fails to render a second time
-+--
Reporter: bhlevca | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI| Version: unspecified
Keywords: |Platform: Linux
Cpu: x86-64 |
-+--
Comment(by annakrat):
Replying to [comment:5 bhlevca]:
Replying to [comment:4 annakrat]:
I tried to replicate and I could not crash it anymore. I guess we'll
have to close this until I find what was I doing, because I was not
dreaming when I reported this.
I believe you, however without being able to reproduce it I can't fix it.
Meanwhile I found that I cannot render two animations. I am using
multiple raster files and not space time raster I am unable to have two
animation in the list and render both. When I am trying to render the
second one I am getting :
{{{
Inconsistent number of maps, please check input data.
}}}
looking in the code I see that only one animation is allowed in non-
temporal mode. Any reason for that? Thanks
{{{
if temporalMode == TemporalMode.NONTEMPORAL:
if len(mapCount) 1:
raise GException(_(Inconsistent number of maps, please
check input data.))
}}}
That's probably a bad name for this variable. But anyway, you have
probably inconsistent number of maps in each animation. You have to have
the same number of maps in each animation when using non temporal mode.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2214#comment:6
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Massimo wrote: Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side. the locally run grass session doesn't have to be more generous in what it can accept, it's just that the local user is trusted already, and so we can get away with not having to harden every possible input. Sure we should clean those up, but there are thousands of them to fix and avoiding giving shell access to users who already have it makes the job more a matter of helping them to avoid crashes than protecting themselves from their own user account. but, even if(/when :) we did think the code was safe from buffer overflows and injection attacks, the web ui should still sanitize inputs as an extra layer of protection, since no software can be trusted to be perfect. ? Is this not true: Any public http ipython notebook should be running in an isolated per-session chroot jail, much like many ftp servers do, and the ipython server's port should be firewalled off from accepting connections from anything other than localhost. And even in a chroot jail a few big loops could use up all the given RAM or disk space by mistake or on purpose. -- As a general thing- GSoC students are by definition still students, and I'm sure that most of us could stand to improve our coding habits too, and would welcome the opportunity. It is the mentors' role to review and teach as much as it is the student's summer job to produce code. The side goal of GSoC is to have a formal avenue to train and grow the future dev team. The more the student knows coming in the better, but we shouldn't expect them to always be experienced vetrans. Somewhere in the middle is a nice balance point. :) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
On Mar 11, 2014, at 12:22 AM, Vaclav Petras wenzesl...@gmail.com wrote: On Mon, Mar 10, 2014 at 11:04 PM, epi massimodisa...@gmail.com wrote: Vaclav, Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side. Develop the sanitizer on the web-ui code and do not touch the g.parser source code. The sanitizer code will following the guidelines found at the page [thanks] you pointed : “Complete Structure Members Table” but extending the restrictions to what Glynn suggested : size constraint, alphanumeric characters, maximum number of items in a list and more. this restriction will be true for the web-ui but not for the desktop gui hence the need to leave untouched the grass command line parser code. does this make sense for you ? Yes, it does. For example, if module accepts parameter of type string, parser checks nothing in this case. However, web UI (1) should have the information (obtained from `--interface-description` XML) that it is a string and restrict the string to 255 characters (just an example). That’s how we’d like to design the gui modules, using g.parser to generate the module descriptions and then use this information to generate the code to render each module. i Guess wx gui works this way. PyQt does something similar with .ui files generated in designer. In our case the .ui is the module description and is generated by g.parser. (1) Actually, both the web GUI and something which is behind it on server side should have this check. In GUI, you want to tell the user that the input is invalid before sending the data for processing but also once data are at the server they should be checked again for case that somebody is not using the GUI but just sending the data to server side of the application (in order to bypass the GUI check). The web development framework may (or may not) solve these two steps for you at once. I can see your idea of having the gui code to do a first check when the module is filled on the client and a second check server side when the instruction is received. thanks to share it. Essentially any command string received by the server will be parsed and checked for the validity of each entry (in regards of the module being executed) . This make perfectly sense to me. Massimo. Vaclav Massimo. On Mar 10, 2014, at 10:32 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Mon, Mar 10, 2014 at 10:19 PM, epi massimodisa...@gmail.com wrote: Glynn, I understood the risk and I agree in toto with you. For the web-ui interface we can define the rules for each kind of entry and publish the rules/restriction on a help page . Then when an invalid input exception is raised the ui will point the user to read the rules page. This is what GRASS parser system [1] is trying to define, so you should/need to use it for that. However, it might not be sufficient (1). In this case, you should not try to workaround it but suggest and improvement for GRASS parser instead. (1) E.g. standard options [2] are defined in the library and modules are using them but they are not visible in the interface (since they are translated to more basic types), so some information is lost. [1] http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html [2] http://grass.osgeo.org/programming7/parser__standard__options_8c.html Massimo. On Mar 10, 2014, at 12:02 PM, Glynn Clements gl...@gclements.plus.com wrote: epi wrote: 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/ ;) That's the main thing. If you allow the user to e.g. provide names for maps, such names should be limited to alphanumeric characters and limited to a reasonable length. If you allow the user to provide a list of inputs, limit both the maximum number of items and the total length of the resulting textual representation. And so on. In short, GRASS modules are designed for use by local users who already have shell access, so there hasn't been any need to program defensively. The OS prevents people from e.g. reading or writing files which they aren't supposed to. -- 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
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
On Mar 11, 2014, at 12:36 AM, Hamish hamis...@yahoo.com wrote: Massimo wrote: Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side. the locally run grass session doesn't have to be more generous in what it can accept, it's just that the local user is trusted already, and so we can get away with not having to harden every possible input. Sure we should clean those up, but there are thousands of them to fix and avoiding giving shell access to users who already have it makes the job more a matter of helping them to avoid crashes than protecting themselves from their own user account. but, even if(/when :) we did think the code was safe from buffer overflows and injection attacks, the web ui should still sanitize inputs as an extra layer of protection, since no software can be trusted to be perfect. gotcha. I personally think of the web-ui user as a trusted user with his own home on the server, but i agree about the need to have an extra layer of security on the web-ui to check user inputs (a web app can be easily victim of malaware etc. enabling the possibility for the user to loose control of the app, but that’s an extreme case) ? Is this not true: Any public http ipython notebook should be running in an isolated per-session chroot jail, much like many ftp servers do, and the ipython server's port should be firewalled off from accepting connections from anything other than localhost. And even in a chroot jail a few big loops could use up all the given RAM or disk space by mistake or on purpose. I see the implementation of the grass-web-shell as a second step in the web-ui development. Most of its security issue depends by the user/admin needs. I have an ipython notebook running on a remote server, it has a password and runs in https with an ssl cert. in my use case each each ipython instance runs on a specific port and use a different ssl cert. (all this settings are stored in the ipytohn notebook profile) … It is not super-secure but is is enough from my needs, we are a small group (4) of trusted and well known users. When the security needs are a high priority, tools like docker [1] , lxc [2] , supervisors [3] will let us to have more control reducing security risk. But this king of thing is isolated from the web-ui development. In any case the IPython-dev team is working hard on this direction, they just released 2.0 and from the roadmap [4] the multiuser interface will be released in the 3.0 version (coming out this summer) [1] https://www.docker.io/ [2] https://linuxcontainers.org/ [3] http://supervisord.org/ [4] https://github.com/ipython/ipython/wiki/Roadmap:-IPython [5] https://github.com/cni/ipython-hydra an old (1year) approach used at the university of standford to allow a multiuser interface to the IPYthon notebook -- As a general thing- GSoC students are by definition still students, and I'm sure that most of us could stand to improve our coding habits too, and would welcome the opportunity. It is the mentors' role to review and teach as much as it is the student's summer job to produce code. The side goal of GSoC is to have a formal avenue to train and grow the future dev team. The more the student knows coming in the better, but we shouldn't expect them to always be experienced vetrans. Somewhere in the middle is a nice balance point. :) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
googling i found the ulimit should take care of memory usage : https://unix.stackexchange.com/questions/34334/how-to-create-a-user-with-limited-ram-usage http://ss64.com/bash/ulimit.html On Mar 11, 2014, at 1:20 AM, epi massimodisa...@gmail.com wrote: On Mar 11, 2014, at 12:36 AM, Hamish hamis...@yahoo.com wrote: Massimo wrote: Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side. the locally run grass session doesn't have to be more generous in what it can accept, it's just that the local user is trusted already, and so we can get away with not having to harden every possible input. Sure we should clean those up, but there are thousands of them to fix and avoiding giving shell access to users who already have it makes the job more a matter of helping them to avoid crashes than protecting themselves from their own user account. but, even if(/when :) we did think the code was safe from buffer overflows and injection attacks, the web ui should still sanitize inputs as an extra layer of protection, since no software can be trusted to be perfect. gotcha. I personally think of the web-ui user as a trusted user with his own home on the server, but i agree about the need to have an extra layer of security on the web-ui to check user inputs (a web app can be easily victim of malaware etc. enabling the possibility for the user to loose control of the app, but that’s an extreme case) ? Is this not true: Any public http ipython notebook should be running in an isolated per-session chroot jail, much like many ftp servers do, and the ipython server's port should be firewalled off from accepting connections from anything other than localhost. And even in a chroot jail a few big loops could use up all the given RAM or disk space by mistake or on purpose. I see the implementation of the grass-web-shell as a second step in the web-ui development. Most of its security issue depends by the user/admin needs. I have an ipython notebook running on a remote server, it has a password and runs in https with an ssl cert. in my use case each each ipython instance runs on a specific port and use a different ssl cert. (all this settings are stored in the ipytohn notebook profile) … It is not super-secure but is is enough from my needs, we are a small group (4) of trusted and well known users. When the security needs are a high priority, tools like docker [1] , lxc [2] , supervisors [3] will let us to have more control reducing security risk. But this king of thing is isolated from the web-ui development. In any case the IPython-dev team is working hard on this direction, they just released 2.0 and from the roadmap [4] the multiuser interface will be released in the 3.0 version (coming out this summer) [1] https://www.docker.io/ [2] https://linuxcontainers.org/ [3] http://supervisord.org/ [4] https://github.com/ipython/ipython/wiki/Roadmap:-IPython [5] https://github.com/cni/ipython-hydra an old (1year) approach used at the university of standford to allow a multiuser interface to the IPYthon notebook -- As a general thing- GSoC students are by definition still students, and I'm sure that most of us could stand to improve our coding habits too, and would welcome the opportunity. It is the mentors' role to review and teach as much as it is the student's summer job to produce code. The side goal of GSoC is to have a formal avenue to train and grow the future dev team. The more the student knows coming in the better, but we shouldn't expect them to always be experienced vetrans. Somewhere in the middle is a nice balance point. :) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
