RE: sessionid-encoded URLs patch

wally,

i think the problem i'm trying to solve is a bit different from what you're
talking about. this doesn't have much to do with keys, but with the content
being cached.

the issue is that oscache indiscriminately caches whatever it sees. say your
page uses response.encodeURL() to encode your links, you'll get a link
_within the content_ that looks like
"http://www.blah.com/page.jsp;jsessionid=2034982034". when oscache caches
this, the next user to load this page will see that link with that
sessionid.

i'm not 100% sure how session ids work, and i guess it depends on your app
server, but that could be a security hole... and even if its not a security
hole, it means that your sessions won't work for people who turn cookies
off.

so my patch fixes this problem (for the taglibs only). for pages that could
have links like this in the content, it will strip out the session id and
stick in a placeholder and put that version in the cache. so next time you
load the cached version, it'll replace the placeholder with the current
cache id.


one alternative solution to this is to only use the session scope for
caching, but that doesn't seem so useful.

another alternative would be to provide listeners that have access to the
HttpServletRequest object.

--alex

> -----Original Message-----
> From: Wally Bowles [mailto:[email protected]]
> Sent: Thursday, December 04, 2003 11:44 AM
> To: Alex Burgel; oscache
> Subject: Re: [Opensymphony-oscache] sessionid-encoded URLs patch
>
>
> Alex,
>
> My 2 cents on this.
>
> As I see oscache has 2 ways of coming up with unique keys for
> content to be put in the cache.
> 1. URL based keys.
> 2. Developer supplied keys.
>
> The cache is scoped based, application or session scoped, the
> default being application scope.
>
> When using APPLICATION scope:
>
> URL based keys in application scope, (i.e. cached content that
> applies to the entire application),
> I think it makes sense, to not include the jsessionid variable
> found in the URL when oscache
> generates the entry key for the content to be cached. Leave the
> jsession in the URL so the servlet
> can tie it back to a session, but in the oscache world the key
> generated will be generic and not
> for a specific established session.  This would allow other
> sessions to get to this application
> wide cached content.
>
> This logic would also work for the oscache-filter for mapped URLs
> that are application-scoped as
> well.
>
> When using SESSION scope:
>
> Here I am not sure?  I have not really paid any attention how
> oscache is keeping cached content
> for a specific session, so I cant help here.
>
> My blind guess, currently oscache handles caching session-scoped
> content successfully when the URL
> does NOT have the jsessionid in it.
>
> If jsessionid is found in the URL, again removing it when
> generating the key may do the trick.
>
> Wally
>
>
> --- Alex Burgel <[email protected]> wrote:
> > hi,
> >
> > i put a patch in jira
> > (http://jira.opensymphony.com/secure/ViewIssue.jspa?id=22549)
> >
> > it attempts to solve the problem of caching pages with session
> ids encoded
> > in URLs.
> >
> > the patch is just a first attempt, so there are some issues...
> notably, it
> > doesn't fix anything with the cache filter, in fact it might
> have broken it.
> > but aside from that it, it works well.
> >
> > it works by taking pages that could possibly have a session id
> in them, and
> > running them through a filter which replaces the id with a token... then
> > when the page is removed from the cache it replaces the token with the
> > current id.
> >
> > the downside is that it requires 2 versions of each page, 1
> with the session
> > token, and 1 without.
> >
> > it requires a new property in the oscache.properties file
> > 'cache.use.session.flag.in.key' which is false by default. set
> it to true to
> > get this all to work...
> >
> >
> > please take a look at the patch and send me any comments.
> >
> > thanks.
> >
> > --alex
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Opensymphony-oscache mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-oscache
>
>
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
>




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/