(keitai-l) Re: AU Phones, Cookies and SSL

From: Curt Sampson <cjs_at_cynic.net>
Date: 08/13/05
Message-ID: <Pine.NEB.4.62.0508131230110.19198@angelic.cynic.net>
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  <cjs@cynic.net>   +81 90 7737 2974

***   Contribute to the Keitai Developers' Wiki!   ***
***           http://www.keitai-dev.net/           ***
Received on Sat Aug 13 06:40:35 2005