On Oct 22, 6:34 pm, SergeyPo <ser...@zarealye.com> wrote:
> 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.
If you were using mod_wsgi instead of mod_proxy to separate web2py
process, then all you need to do to make better use of multiprocessor
type system is be running it under Apache in multiprocess
configuration.
Have a read of:
http://blog.dscpl.com.au/2007/09/parallel-python-discussion-and-modwsgi.html
Graham
> 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/2806andreferencestherein,
> > > >>> 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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
