I understand what you are proposing. I need to think about this. At this time we do not have any site level configuration file and we consider that a plus. options.py is a configuration for the web server only. Then we have routes.py which filters incoming requests and responses.
If the purpose of such a prefix is to allow two web2py instances to run on the same installation then that parameter cannot be set in any of those configurations files else both instances will have the same prefix and that would defy the purpose. This should go in a configuration parameter of setting that is specified when web2py starts. Do you agree? Massimo On Oct 20, 9:26 pm, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > On Oct 21, 12:37 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > > On Oct 20, 8:01 pm, Graham Dumpleton <graham.dumple...@gmail.com> > > wrote: > > > > On Oct 21, 11:14 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > > Sorry my answer was confused. I guess having my son jumping around me > > > > all the time does not help. > > > > > What I tried to say is that web2py cannot link a session to a port > > > > hence the problem. It cannot and should not because the port is not > > > > reliable since there may be a proxy. > > > > web2py shouldn't even be trying to link it to a port. Not what I am > > > suggesting. How cookies work with respect to ports is just how HTTP is > > > and any requirement to work around that should be entirely up to the > > > user tpo do explicitly and not the framework provider try > > > Perhaps I do not understand your proposed solution. As far as I know > > cookies ignore ports seehttp://code.djangoproject.com/ticket/2806 and > > references therein, > > specifically the last comments. > > Cookies can only reliably bind to a hostname and a path. > > I wasn't proposing anything by that statement, just reaffirming that > web2py should be attempting to do anything magic. > > > > > > > There is a flag one can set to change the session name (session.connect > > > > (...appname=...)) but I do not advice using that solution because I > > > > prefer a different solution. To use the Django solution, you would > > > > have to detect the port the server is running on and set the name of > > > > the session cookie accordingly, but I do not like idea of an app that > > > > depends on the port it is running at. For example it would break > > > > download over http of images that requires authentication from pages > > > > that use https. > > > > You wouldn't need for the application to detect the port. If these are > > > two different installations of web2py then they can have separate hard > > > wired configuration setting. Presuming that is that this can be > > > controlled from a global settings file somehow like with Django. > > > I do not think so but perhaps if you can show an example of how you > > would handle it in Django I can provide an equivalent solution in > > web2py. > > At present you have in gluon/globals.py the code: > > class Session(Storage): > > """ > defines the session object and the default values of its members > (None) > """ > > def connect( > self, > request, > response, > db=None, > tablename='web2py_session', > masterapp=None, > migrate=True, > ): > self._unlock(response) > if not masterapp: > masterapp = request.application > response.session_id_name = 'session_id_%s' % masterapp > > So, the 'session_id' prefix is hard coded. > > All you would need to do is allow for that prefix to be overridden in > a global configuration file. Thus avoid might say: > > response.session_id_name = '%s_%s' % (session_id_prefix, > masterapp) > > Where session_id_prefix is grabbed from global user configuration file > and if not set still defaults to 'session_id'. > > I am not sure what file you use for doing that sort of thing. I see > options_std.py and paramaters_XYZ.py but not sure if where such a > global setting should go. > > Not sure if code: > > def get_session(request, other_application='admin'): > """ checks that user is authorized to access other_application""" > > if request.application == other_application: > raise KeyError > try: > session_id = request.cookies['session_id_' > + other_application].value > osession = \ > storage.load_storage(os.path.join(up(request.folder), > other_application, 'sessions', > session_id)) > except: > osession = storage.Storage() > return osession > > in gluon.fileutils.py would also need to change. > > Anyway, this would globally set the prefix and how to add application > name on end wouldn't change. > > Graham > > > > > Instead, consider a typical web2py installation with two apps, a and > > > > b. By default, they will use the cookies session_id_a and > > > > session_id_b, respectively. Sergey can take advantage of this feature > > > > and for example, he can create a symlink "b" to his app "a". Now "a" > > > > and "b" are the same app but they will have distinct session cookies. > > > > He can can access "a" from one port and "b" from the other without > > > > running into issues. > > > > Do you literally mean symlink as in file system symbolic link? Could > > > the alias instead be managed somehow via your global route rewriting > > > rules instead. > > > If you want two discinct sets of session cookies without altering the > > code you need the symbolic links. This solution works with every app. > > > You can also combine routes with a path in the cookie but this > > requires adding one line to the app and this will prevent other apps > > from accessing sessions from this app. Something that I consider a > > feature of web2py for collaborative applications. > > > > Graham > > > > > Massimo > > > > > On Oct 20, 6:41 pm, Graham Dumpleton <graham.dumple...@gmail.com> > > > > wrote: > > > > > > I am talking about the original persons problem. If you think you are, > > > > > then you aren't explaining things very well so the original poster and > > > > > others would possibly be able to understand. At the moment you seem to > > > > > be offering no solution at all. > > > > > > Back to the original problem, a session cookie is by default going to > > > > > be bound to the server host name. Since this disambiguation doesn't > > > > > include the port, you will have problems with having two separate web > > > > > application installations which are under same host name, but > > > > > different ports. The only way to resolve that is for each web > > > > > application instance to use a different name for the name of the > > > > > session cookie. That way two distinct cookies will be recorded in the > > > > > web browser and although both would end up being sent to both > > > > > installed web applications on the separate ports, because they would > > > > > be distinguishing based on the name of the session cookie, they > > > > > wouldn't care about the other and wouldn't interfere with each other. > > > > > > In Django you can set the SESSION_COOKIE_NAME variable in its settings > > > > > file to enable this trick. Does web2py have an equivalent feature > > > > > whereby the name of the session cookie can be overridden? > > > > > If it > > > > > doesn't, then OP poster wouldn't be able to do what he wants and thus > > > > > a limitation of web2py. > > > > > > The only other way that sessions for different web application > > > > > instances using same framework can be distinguished is where they are > > > > > mounted at different non overlapping sub URLs. What would be done here > > > > > is rather than change the name of the session cookie, one would set > > > > > the path attribute of the cookie so that that specific cookie would > > > > > only be sent by the web browser along with requests which fall under > > > > > that sub URL for a host. If that path attribute is not present, the > > > > > default is effectively '/' and so cookie sent no matter what URL is > > > > > for that host. In other words, by setting path attribute of session > > > > > cookie, web browser will separate cookies without needing to change > > > > > the name of the cookie. > > > > > > In Django you can set the SESSION_COOKIE_PATH variable in its settings > > > > > file to enable this trick. Does web2py have an equivalent feature > > > > > whereby the context of what the session cookie applies to can be > > > > > limited? > > > > > > While we are at it, does web2py allow the domain of the session cookie > > > > > to be changed. That is, rather than a session cookie being limited to > > > > > a single host, it could be changed to apply to an enmcompassing parent > > > > > domain. > > > > > > In Django you can set the SESSION_COOKIE_DOMAIN variable in its > > > > > settings file to enable this trick. Does web2py have an equivalent > > > > > feature to control this and as a result would potentially allow a > > > > > single web2py instance to be used to serve multiple host names under > > > > > some common parent domain? > > > > > > So, look up those features of Django and how they work and then answer > > > > > whether web2py has equivalent feature. If the answer for > > > > > SESSION_COOKIE_NAME is yes, the OP can do what he wants. If the answer > > > > > is no, then he can't do what he wants. > > > > > > Graham > > > > > > On Oct 21, 10:18 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > > > > Hi Graham, > > > > > > > the session is linked to the application, not to the web2py > > > > > > installation. If you install the same app twice under web2py, for > > > > > > example, each of them gets its own set of sessions. Each app has its > > > > > > own session name and I think that is what you refer to. > > > > > > > web2py does not allow (by default) the same user to access the same > > > > > > application under the same web2py from the same browser, at the same > > > > > > time, because it would mess up the internal workflow of the > > > > > > applications. If an action does not need to access the session, it > > > > > > can > > > > > > release the lock. > > > > > > > Massimo > > > > > > > On Oct 20, 6:04 pm, Graham Dumpleton <graham.dumple...@gmail.com> > > > > > > wrote: > > > > > > > > Other web frameworks allow you to customise the name of the > > > > > > > session > > > > > > > cookie to avoid this sort of problem where different applications > > > > > > > run > > > > > > > on different ports under same host name. Other web frameworks also > > > > > > > allow one to cleanly mount multiple instances of an application > > > > > > > under > > > > > > > different sub URLs of same host/port and where they need different > > > > > > > session contexts, allow you to have the > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
