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
Quoting Aaron Held <aaron@...>:
> So do you address any security concerns where the application on
> context can affect data in another context? The only way that I
> this working is if you control the entire system. Its not really
> 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
> >I think I may be one of the few folks on here running numerous
> >websites via Webkit, but with one instance (using contexts). They
> >all virtual hosts, our solution is to use mod_webkit so that
> >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
> >not accessible via any non-WebKit sites that happen to be running
> >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
> >ISAPI rewriter written using Boost::RegEx. Let me know if that's
> >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
> >The only event dedicated to issues related to Linux enterprise
> >Webware-discuss mailing list
i find your contempt for naked feet curious.