Well, if he is referring to two different applications, then they have two different cookies, different sessions, different databases, different auth_user tables. Although there are ways around this too.
On Oct 21, 10:20 am, Alex Fanjul <alex.fan...@gmail.com> wrote: > Hi Massimo, > through your thread comments It seems that you always refer to the "same > application" in two instances of the same server, and coming back to the > first Sergay problem, he refers to "two different" applications... > maybe I'm wrong and Sergay wanted to say differente instances... > otherwise would be so strange, isnt it? > > alex F > > Run*two different web2py applications* on same machine using two > different ports (127.0.0.1:8000 and 127.0.0.1:8002). Open two browser > windows for two apps (two tabs in Safari). > Log in 1st application admin in 1st window. > Log in 2nd app admin in 2nd window. > Try to do smth in 1st window - it will ask you for password. > > El 21/10/2009 5:38, mdipierro escribió: > > > 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/2806and > >>> 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? > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
