I'm not sure if this will help but I had an eye awakening experience
on sessions recently as well. It was fortunately a situation where the
site wasn't heavily relying on sessions. We found that the target handsets
(only 2 yippeee) didn't support cookies. And the users of the session
were only going to be the administrators of the site from a test site.
The sessions I was using used Jserv which I did not know at the time...
jserv stores the session in a cookie on the client side. Now there were
a number of solutions to this... one of them URL rewriting. Another (the
one
I used) was to not use sessions on the server side as perse "Java sessions".
Instead I made up a parameter enocoded to represent each user. In eash URL,
I would go through the HTML dynamically and for that user add their session
while it was valid to the end of the URL and in all forms as well. Then I
would pass that information back to the server and it would then be able to
use that little bit of information as a session. Unfortunately in one or
two cases, I needed to send that info though another server which didn't
accept
extra parameters so I used URL rewriting only in that case....... The whole
thing was
a headache but easily doable.
If you use JSP instead... that does somthing similar automatically
without having to send it but I don't like JSP for other reasons....Anyway
if it can be done in Jserv... it can be done with JSP, perl or
whatever....if
you have room for a cookie parameter (make it cool and unhijackable)
or a URL rewrite.
To make the session unhijackable on a handset check the Handset ID
and use it to make the secret code that indicates a session. But don't make
it easy for the hacker to find (like embedding it)...encode it with your
own algorhythm. Then no one can use that value withough getting the
source code. You can do something similar with web clients... if you are
clever enough.
Sessions can be implemented in many ways even without cookies, but its
good
to make them in such a way that they are hard to hijack (without wasting too
much time).
That wiki was really good too!
Curt Sampson wrote:
> On Thu, 26 May 2005 necrodome@gmail.com wrote:
>
> > why don't you try url rewriting for session management?
>
> It's better to use cookies if you can:
>
> The bad part about using URL rewriting is that bookmarks and links
> that people send-around include the session ID, which can result in
> inadvertant session hijacking.
>
> http://www.keitai-dev.net/keitai-wiki?SessionHandling
>
> BTW, there's some other useful stuff on the above page as well. I've got
> some nice tricks for starting out with URL rewriting and dynamically
> switching to cookies, if the browser will return them, that I should
> really post there one day.
>
> cjs
> --
> Curt Sampson <cjs@cynic.net> +81 90 7737 2974
>
> *** Contribute to the Keitai Developers' Wiki! ***
> *** http://www.keitai-dev.net/wiki/ ***
>
> This mail was sent to address paul@thetamusic.com
> Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/
--
-Paul Lester
pbl1@cornell.edu
paul@thetamusic.com
http://members.tripod.com/~pbl1/
--Its in every one of us to be wise...
we can all love ev'rything without
ever knowing why...its in every one
of us...
Received on Sun May 29 05:48:10 2005