webware-discuss

I have written a couple of test sites with WebKit. My server is set up
to virtual host, and I want to have WebKit functionality on a number of
virtual websites.
I need to separate out different ww applications, so that:
http://x.com/cgi-bin/wkcgi/context-x/page and
http://y.com/cgi-bin/wkcgi/context-y/page work, and
http://x.com/cgi-bin/wkcgi/context-y/page and
http://y.com/cgi-bin/wkcgi/context-x/page return 404 errors.
Surely this must be a common problem, but I can't find mention of it. I
am going to add some code to check the server and return the 404 in my
site page classes, but I am thinking this could/should be handled much
earlier in webkit. Ie, when it is searching for the appropriate
context, if the allowed servers were configured in the contexts listed
in Application.config.
Can anyone point me to any useful info?
TIA
Alex

The problem is that Webware runs in a single Python VM, so all of your
contexts will be able to access each other.
If these are seperate apps not under your control I would recommend that
you run multiple instances of Webware. (They can share modules, but each
should run seperately)
Alternatively you can add some code to SitePage.awake and check the URL,
then restrict that URL to a particular context.
-Aaron
Alex King wrote:
>I have written a couple of test sites with WebKit. My server is set up
>to virtual host, and I want to have WebKit functionality on a number of
>virtual websites.
>
>I need to separate out different ww applications, so that:
>
>http://x.com/cgi-bin/wkcgi/context-x/page and
>http://y.com/cgi-bin/wkcgi/context-y/page work, and
>
>http://x.com/cgi-bin/wkcgi/context-y/page and
>http://y.com/cgi-bin/wkcgi/context-x/page return 404 errors.
>
>Surely this must be a common problem, but I can't find mention of it. I
>am going to add some code to check the server and return the 404 in my
>site page classes, but I am thinking this could/should be handled much
>earlier in webkit. Ie, when it is searching for the appropriate
>context, if the allowed servers were configured in the contexts listed
>in Application.config.
>
>Can anyone point me to any useful info?
>
>TIA
>
>Alex
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Webware-discuss mailing list
>Webware-discuss@...
>https://lists.sourceforge.net/lists/listinfo/webware-discuss
>
>

> >I need to separate out different ww applications, so that:
> >
> >http://x.com/cgi-bin/wkcgi/context-x/page and
> >http://y.com/cgi-bin/wkcgi/context-y/page work, and
> >
> >http://x.com/cgi-bin/wkcgi/context-y/page and
> >http://y.com/cgi-bin/wkcgi/context-x/page return 404 errors.
> >
> >Surely this must be a common problem, but I can't find mention of
> it.
I think I may be one of the few folks on here running numerous
websites via Webkit, but with one instance (using contexts). They are
all virtual hosts, our solution is to use mod_webkit so that wkcgi/
is never directly available.
So all content (with the exception of images and certain defined
directories) on http://x.com/(.*) is transparently re-written to
http://x.com/wkcgi/context-x/$1. (Actually, we use /WK mod_webkit,
but the same idea holds.) We also do a little munging so that /WK is
not accessible via any non-WebKit sites that happen to be running on
the server, but that's optional.
Summary: I recommend using mod_rewrite to hide full webkit access.
(I assume you're using Apache; we have a similar setup on IIS, but
there is no builtin equivalent to mod_rewrite, so we use a small C++
ISAPI rewriter written using Boost::RegEx. Let me know if that's your
situation, and I'll point you in the right direction. But it looks
like you're using apache.)
- Luke

So do you address any security concerns where the application on one
context can affect data in another context? The only way that I see
this working is if you control the entire system. Its not really good
for a virtual webhosting situation where you want to sell contexts.
-Aaron Held
Luke Opperman wrote:
>>>I need to separate out different ww applications, so that:
>>>
>>>http://x.com/cgi-bin/wkcgi/context-x/page and
>>>http://y.com/cgi-bin/wkcgi/context-y/page work, and
>>>
>>>http://x.com/cgi-bin/wkcgi/context-y/page and
>>>http://y.com/cgi-bin/wkcgi/context-x/page return 404 errors.
>>>
>>>Surely this must be a common problem, but I can't find mention of
>>>
>>>
>>it.
>>
>>
>
>I think I may be one of the few folks on here running numerous
>websites via Webkit, but with one instance (using contexts). They are
>all virtual hosts, our solution is to use mod_webkit so that wkcgi/
>is never directly available.
>
>So all content (with the exception of images and certain defined
>directories) on http://x.com/(.*) is transparently re-written to
>http://x.com/wkcgi/context-x/$1. (Actually, we use /WK mod_webkit,
>but the same idea holds.) We also do a little munging so that /WK is
>not accessible via any non-WebKit sites that happen to be running on
>the server, but that's optional.
>
>Summary: I recommend using mod_rewrite to hide full webkit access.
>
>(I assume you're using Apache; we have a similar setup on IIS, but
>there is no builtin equivalent to mod_rewrite, so we use a small C++
>ISAPI rewriter written using Boost::RegEx. Let me know if that's your
>situation, and I'll point you in the right direction. But it looks
>like you're using apache.)
>
>- Luke
>
>
>
>-------------------------------------------------------
>Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
>The only event dedicated to issues related to Linux enterprise solutions
>www.enterpriselinuxforum.com
>
>_______________________________________________
>Webware-discuss mailing list
>Webware-discuss@...
>https://lists.sourceforge.net/lists/listinfo/webware-discuss
>
>

Correct, this is really a scenario for a single development
organization. So we do not directly address cross-context security.
If the original request was about reselling Webware hosting, my
approach would not be appropriate.
(We have systems in place where accidental mixing of data would be
highly unlikely, with context-specific SitePages that define the
datasource that all data access is wrapped around. Separate db user
per context, etc. Just a safety net, not a security measure. :)
Just a note: even if you're running separate Webware instances, there
is the possibility for malicious manipulating of any files that are
writable by the webware-running *user*, so for a vhost reseller
situation I would recommend either running webware under each
specific user's account, or preferrably a solid chroot/vserver
environment.
- Luke
Quoting Aaron Held <aaron@...>:
> So do you address any security concerns where the application on
> one
> context can affect data in another context? The only way that I
> see
> this working is if you control the entire system. Its not really
> good
> for a virtual webhosting situation where you want to sell contexts.
>
> -Aaron Held
>
>
>
> Luke Opperman wrote:
>
> >>>I need to separate out different ww applications, so that:
> >>>
> >>>http://x.com/cgi-bin/wkcgi/context-x/page and
> >>>http://y.com/cgi-bin/wkcgi/context-y/page work, and
> >>>
> >>>http://x.com/cgi-bin/wkcgi/context-y/page and
> >>>http://y.com/cgi-bin/wkcgi/context-x/page return 404 errors.
> >>>
> >>>Surely this must be a common problem, but I can't find mention
> of
> >>>
> >>>
> >>it.
> >>
> >>
> >
> >I think I may be one of the few folks on here running numerous
> >websites via Webkit, but with one instance (using contexts). They
> are
> >all virtual hosts, our solution is to use mod_webkit so that
> wkcgi/
> >is never directly available.
> >
> >So all content (with the exception of images and certain defined
> >directories) on http://x.com/(.*) is transparently re-written to
> >http://x.com/wkcgi/context-x/$1. (Actually, we use /WK mod_webkit,
> >but the same idea holds.) We also do a little munging so that /WK
> is
> >not accessible via any non-WebKit sites that happen to be running
> on
> >the server, but that's optional.
> >
> >Summary: I recommend using mod_rewrite to hide full webkit access.
> >
> >(I assume you're using Apache; we have a similar setup on IIS, but
> >there is no builtin equivalent to mod_rewrite, so we use a small
> C++
> >ISAPI rewriter written using Boost::RegEx. Let me know if that's
> your
> >situation, and I'll point you in the right direction. But it looks
> >like you're using apache.)
> >
> >- Luke
> >
> >
> >
> >-------------------------------------------------------
> >Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa
> Clara
> >The only event dedicated to issues related to Linux enterprise
> solutions
> >www.enterpriselinuxforum.com
> >
> >_______________________________________________
> >Webware-discuss mailing list
> >Webware-discuss@...
> >https://lists.sourceforge.net/lists/listinfo/webware-discuss
> >
> >
>
>
--
i find your contempt for naked feet curious.

On Wed, 2003-05-07 at 08:48, Aaron Held wrote:
> So do you address any security concerns where the application on one
> context can affect data in another context? The only way that I see
> this working is if you control the entire system. Its not really good
> for a virtual webhosting situation where you want to sell contexts.
No, selling contexts where users get to edit scripts (even Cheetah
templates!) won't work. I don't see any resolution, except to implement
security ala Zope (proxies, restricted execution, etc), which I would
strongly advise against.
Untrusted users should always have separate AppServers. I would go
further to say that discrete applications should have separate
AppServers. You can achieve pretty good security by running different
users' AppServers as the respective user, and thus being able to
leverage the operating system's permissions and security mechanisms.
Ian

On Tue, May 06, 2003 at 06:11:18PM -0500, Luke Opperman wrote:
>
> > >I need to separate out different ww applications, so that:
> > >
> > >http://x.com/cgi-bin/wkcgi/context-x/page and
> > >http://y.com/cgi-bin/wkcgi/context-y/page work, and
> > >
> > >http://x.com/cgi-bin/wkcgi/context-y/page and
> > >http://y.com/cgi-bin/wkcgi/context-x/page return 404 errors.
> > >
> > >Surely this must be a common problem, but I can't find mention of
> > it.
>
> I think I may be one of the few folks on here running numerous
> websites via Webkit, but with one instance (using contexts). They are
> all virtual hosts, our solution is to use mod_webkit so that wkcgi/
> is never directly available.
>
> So all content (with the exception of images and certain defined
> directories) on http://x.com/(.*) is transparently re-written to
> http://x.com/wkcgi/context-x/$1. (Actually, we use /WK mod_webkit,
> but the same idea holds.) We also do a little munging so that /WK is
> not accessible via any non-WebKit sites that happen to be running on
> the server, but that's optional.
>
> Summary: I recommend using mod_rewrite to hide full webkit access.
>
> (I assume you're using Apache; we have a similar setup on IIS, but
> there is no builtin equivalent to mod_rewrite, so we use a small C++
> ISAPI rewriter written using Boost::RegEx. Let me know if that's your
> situation, and I'll point you in the right direction. But it looks
> like you're using apache.)
>
> - Luke
I've got apache, but I'm trying to migrate to thttpd, hence using wkcgi
and no mod_rewrite. I have used the following in my sitepage class:
def respond(self,trans):
if trans.request().serverDictionary()['SERVER_NAME'] in self.getallowedsitenames():
SidebarPage.respond(self,trans)
else:
res = trans.response()
res.setHeader('Status', '404 Error')
res.write("""<html> ....
(my site class is derived from SidebarPage)
This works for what it does, but as others have alluded to there are
other problems, eg. sessions are shared between sites (contexts), so
loggin in at one site means you are logged in at all of them. I need
more code to clear the session state when switching sites. (Or do this a
different way.)
My situation is that all the webware sites are written by me, I'm not
renting out virtual servers, I'm developing website solutions for
clients myself, so I have control over the code. I considered having
separate webware installations for each client, and in many ways this
would be the best solution, but it seems like overkill for a few lightly
used sites. (and I don't want to clutter my ps listing :)
Alex

>
>
>This works for what it does, but as others have alluded to there are
>other problems, eg. sessions are shared between sites (contexts), so
>loggin in at one site means you are logged in at all of them. I need
>more code to clear the session state when switching sites. (Or do this a
>different way.)
>
>
If you use different a host.domain.com and use cookie sessions then the
browser will manage two different sessions when accessing your site.
The browser will only send the cookie for that particular domain so in
your case it may not be an issue.
You could also have a slight differnce in your user object. I just set a
User.company flag and then in secure page I did something like
if user.company = 'scomsci' or user.company='metrony':
login....
In my login I did :
SQL = select * from users where username=%s AND password=%s and company
in ('%s', 'metrony')
This way I could use my account to login in to any site, but then again
I am lazy.
See - its a Feature.

With regards to the session issue, our common SitePage overrides any
session sets/gets and prefixes the context name to the session
variable name. So there's no direct way for separate sites to access
another's session variables.
- Luke
Quoting Alex King <alex@...>:
> This works for what it does, but as others have alluded to there
> are
> other problems, eg. sessions are shared between sites (contexts),
> so
> loggin in at one site means you are logged in at all of them. I
> need
> more code to clear the session state when switching sites. (Or do
> this a
> different way.)
>
> My situation is that all the webware sites are written by me, I'm
> not
> renting out virtual servers, I'm developing website solutions for
> clients myself, so I have control over the code. I considered
> having
> separate webware installations for each client, and in many ways
> this
> would be the best solution, but it seems like overkill for a few
> lightly
> used sites. (and I don't want to clutter my ps listing :)
>
> Alex
>
--
i find your contempt for naked feet curious.

Where does this happen??
I have a Webware 5 site that uses somthing like Application.Sessions()
to pull in a list of all sessions regardless of the Context (I think,
that was a long time ago and I no longer have admin access to the site)
-Aaron
Luke Opperman wrote:
>With regards to the session issue, our common SitePage overrides any
>session sets/gets and prefixes the context name to the session
>variable name. So there's no direct way for separate sites to access
>another's session variables.
>
>- Luke
>
>
>

self.session() is setup in WebKit.Page to be transaction.session().
These sessions are per-user, across contexts.
Webkit.Page.session():
def session(self):
if not self._session:
self._session = self._transaction.session()
return self._session
Our SitePage.session():
def session(self):
return SessionWrapper(self.request().contextName(),
Page.session(self))
and SessionWrapper passes most requests through to the real session,
but overrides the following to affect the name/values before passing
through:
value(self, name)
hasValue(self, name)
setValue(self, name, value)
values(self)
invalidate(self)
That's all. Actually, SessionWrapper might be a subclass of
WebKit.Session now, I don't have the code right in front of me and I
know it's gone through a refactoring or two.
- Luke
Quoting Aaron Held <aaron@...>:
> Where does this happen??
> I have a Webware 5 site that uses somthing like
> Application.Sessions()
> to pull in a list of all sessions regardless of the Context (I
> think,
> that was a long time ago and I no longer have admin access to the
> site)
>
> -Aaron
>
> Luke Opperman wrote:
>
> >With regards to the session issue, our common SitePage overrides
> any
> >session sets/gets and prefixes the context name to the session
> >variable name. So there's no direct way for separate sites to
> access
> >another's session variables.
> >
> >- Luke

Hi,
I've been using raw SQL in my servlets and haven't made true objects for
Accounts, Users, etc. Now I'm kicking myself because the maintenance is a
pain. So I'm re-writing it all to use objects but my tables are in Postgres
and I remember MySQL being tested with MiddleKit but not Postgres. Does
anyone use MiddleKit with Postgres? Are there any gotchas? Do I need
patches? etc.
Are people using other middleware with Webware? I'm on a really short
schedule, like early next week, to get this conversion done. From your
experience, is that realistic?
Thanks,
Jeff

Thanks everyone for the responses on middleware! I'm going to hold off on the
conversion to using middleware for a week or two so I can meet a deadline and
learn more about the various options you all told me about. Our db schema
already exists so that will be one limiting factor on which way I go. Maybe
I can change to a new schema generated by middleware but that would be a
project in itself. I'll keep you posted.
Thanks again,
Jeff