Yes I was running two different applications, and that's what wondered me - why different apps (actually two different python web2py processes) affected each other. I still prefer to keep things simple and avoid various configuration files but do you agree, this is completely normal approach if I happen to run two different web2py instances on same server, on different ports? This is very beneficial from system point of view, e.g. Apache mod_proxy is easy to setup for different ports listening different domain names, or with multicore processors, having two separate python processes makes use of separate cores and thus allows concurrency. If I install the two apps into single web2py instance it would run in same python thread... you understand me.
On Oct 21, 7:30 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > 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/2806andreferences 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 > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
