I read your wiki article, nice site by the way, and see where you are coming from. I must have been confused before because I didn't realise you were using the session technique AND cookies to achieve the same result.
I do agree that the URL rewriting can cause problems when the Session ID is passed in bookmarks, emailed to friends or, as one of our clients recently did, actually advertised as part of the URL in a mailshot. However, this can be, for most situations, worked around by setting the session timeout to something quite short, like 15 minutes and ensuring the server flushes all the user specific data regularly; and by using a sufficiently long and random session ID.
You did say in the wiki that URL rewriting is a lot of work, I had the luxury of using PHP to automate this process so didn't have to edit / write any code but if you are using Java with something like the Websphere app server then yeah there is a little bit more work to do.
One thing I am not sure about, from a practical point of view, is whether or not the extra characters needed in the URL to hold the session ID really will cause problems in terms of extra file size. I think only the vodafones may have trouble displaying a page because they generally have quite tight file limits as default, but apart from the extra packet charges which would probably be negligible I think the extra length is acceptable if it gives extra functionality to the site. What are your views on this ?
As for the original question you posted about the cookie being dropped on AU, I read from that last link I sent that only some phones actually hold the cookie on the handset and the rest hold it on the server. So that would explain why, when you open the secure port directly to the handset only some phones would have the original cookie information on the handset. The rest would have had that information stored on the ezweb servers. I think this would be pretty hard to work around and your problem will be solved as the handset technology progresses and all phones hold the cookie locally. Would you agree with this reasoning ?
Well as a result of your posts I would now like to explore the cookies on AU more as its likely that the other carriers will start implementing them soon. However, I will avoid using them just yet and stick to the URL rewriting work around for now until Docomo change their approach and start accepting cookies. I base this reasoning purely on the fact that Docomo have the dominant market share so most of the phones using the service wont accept cookies and I don't like doing extra work unless it is absolutely necessary :D
Marcus
http://cellsuite.blogspot.com
Curt Sampson <cjs@cynic.net> wrote:
On Fri, 12 Aug 2005, marcus saw wrote:
> Sure thing, like I said I encountered a similar problem but worked
> around it by using a session
A "session" is, in general usage, a set of common information for a
related series of requests from a particular user on a particular
browser. Often this information is stored internally on a server, and
identified with a key somehow exchanged between the client and the
server.
Thus, when it worked on other systems, I was using a session. When it was
broken on AU, I was still using a session. When I made a hack to fix it
on AU, I was yet again, still using a session.
It doesn't make any sense to talk about sessions here, because sessions
are not at all the problem. The problem is AU's handling of cookies,
which still exists if the cookies are something other than session
information.
> the session key was passed from page to page in the URL using URL
>rewriting for all the carriers, AU and Docomo included. So what this
>means that the client never actually 'held' the session key, just every
>link on the page was automatically re-writen to include it in the query
>string.
I understand that. But there are very, very good reasons to avoid URL
rewriting whenever you can. See the end of
http://www.keitai-dev.net/keitai-wiki?SessionHandling
for a few notes on this.
> I did this because there was no other way to garantee a unique ID to
> identify each phone.
As far as I can tell, cookies work fine on AU, except for this one
issue.
> If you intend to support more than just the latest AU phones then
>maybe you will find it useful to try this approach.
If you re-read my previous post, I hope you will see that I have been
using this approach all along for any browsers that do not return
cookies. I automatically determine, with each request, whether or not I
need to do URL rewriting, and turn it on or off as appropriate.
> I dug out this link which has some more AU
>specific information about how they handle cookies
>http://www.au.kddi.com/ezfactory/tec/spec/cookie.html
Ah, thanks for that! I'd not seen it before. I'll check it out soon.
> By the way, if you can find an alternative way to achieve what you
> want to do then please let me know - I would be very interested in
> hearing more.
I explained that in an earlier post. When doing a redirect from an http
to an https page, I turn on URL rewriting for that one redirect. That
allows my system to find the session for that initial https request.
I always issue a Set-Cookie header with every response, so the second
https request will include the session ID in both a cookie and the URL.
On seeing this, I know that the client returns cookies, and so I turn
off URL rewriting.
I should put a full explanation of this on to the page I mentioned
Iabove. 'll try to do that next week.
cjs
--
Curt Sampson +81 90 7737 2974
*** Contribute to the Keitai Developers' Wiki! ***
*** http://www.keitai-dev.net/ ***
This mail was sent to address saw_marcus@yahoo.com
Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/
---------------------------------
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.
Received on Sun Aug 14 05:40:06 2005