No Cookie: how to implement session?

  • Thread starter Sullivan WxPyQtKinter
  • Start date
S

Sullivan WxPyQtKinter

I do not want to use Cookies in my site since not all web browser
support it well and sometimes people close cookie functioning for
security reasons.

I tried to add hidden field with a sessionID in every python CGI script
generated web pages, so everytime my client POST a request, the server
will retrieve the sessionID and decide if it is in the same session.
However, since python cgi do not have a function for redirecting to a
page, I use Location: url http head or <body
onload="document.location=\'%s\'"></body> javascript for
redirecting.in this case, hidden field could not be used any more.

Really wish python would have session management or equivalent in
standard CGI module~~~~
 
D

Dennis Lee Bieber

I do not want to use Cookies in my site since not all web browser
support it well and sometimes people close cookie functioning for
security reasons.
Yes... And watch them flounder on sites that use cookies /for/ a
form of security (ie, those sites that require logins...) Cookies can be
set to expire, so the "session" can time-out... whereas...
I tried to add hidden field with a sessionID in every python CGI script
generated web pages, so everytime my client POST a request, the server

This would imply that a client could start a session today, and
finally submit tomorrow... There's no real time-out capability unless
you run some background timer thread for each "session ID"...
will retrieve the sessionID and decide if it is in the same session.
However, since python cgi do not have a function for redirecting to a
page, I use Location: url http head or <body

Isn't redirect normally the responsibility of the web server
/before/ invoking the CGI script itself? I'll concede I'm weak on that
level of detail.
Really wish python would have session management or equivalent in
standard CGI module~~~~

The standard CGI module is only the lowest common base for dynamic
web pages. The technology goes back decades, possibly even predating
cookies. Look at the name: Common Gateway Interface... It's a building
block responsible for getting submitted form data, as passed by the web
server environment, and returning generated data -- the interface
between an application and the web server. All else must be built on top
of it -- hence separate modules for Cookie control, etc.
--
 
P

Paul Rubin

Dennis Lee Bieber said:
Yes... And watch them flounder on sites that use cookies /for/ a
form of security (ie, those sites that require logins...) Cookies can be
set to expire, so the "session" can time-out... whereas...

Sites should never rely on cookies timing out. If there's any
security concern about session persistence and you don't want to track
the session timeout on the server, then encode an expiration time into
the cookie itself, and cryptographically authenticate the cookie.

The trouble here is that it stops internal links (retrieved with GET
rather than POST) from working. So normally what you're describing is
done with session ID's in the url (see amazon.com for example). That,
too, isn't so great for security, especially for ecommerce sites,
since people tend to share url's with their friends. E.g., they'll
post to Usenet or web bbs's, So-and-so is offering a great deal on
Python manuals, the url is <http://whatever...> where "whatever"
includes the session ID. Anyone clicking the url then ends up with
the same shopping cart as the person who posted it.

To OP: keep in mind also that anyone who disables cookies probably
also disables javascript, so relying on javascript as you described
for redirection doesn't work too well either.
 
S

Sullivan WxPyQtKinter

As you said, ....There is no solution? I mean, tracing a real session
without using tricks like hidden field and cookies in CGI script?
Dennis Lee Bieber 写é“:
 
A

Alex Martelli

Sullivan WxPyQtKinter said:
As you said, ....There is no solution? I mean, tracing a real session
without using tricks like hidden field and cookies in CGI script?

Cookies aren't "tricks" -- they are THE standard, architected solution
for session persistence in HTTP 1.1 -- people who disable them are
saying they do not *WANT* persistent sessions... on their heads be it.


Alex
 
P

Paul Rubin

Cookies aren't "tricks" -- they are THE standard, architected solution
for session persistence in HTTP 1.1 -- people who disable them are
saying they do not *WANT* persistent sessions... on their heads be it.

That so many people do this is partly the fault of browsers. Until
recently, there was no way to configure most browsers to accept all
cookies but treat them as ephemeral (dispose of them when you close
the browser). Your choices were:

1) accept all cookies; non-ephemeral ones would persist on your hard disk
2) accept only ephemeral cookies: ones marked non-ephemeral would be
ignored
3) ignore ALL cookies

Choice #1 enables invasive long-term user tracking that is not
necessary for mere session persistence.

Choice #2 stops the long-term tracking, but session cookies get
ignored if they have an expiration date (that makes them
non-ephemeral). That stops most session cookies from working. This
choice was available in some versions of Netscape Communicator but I
don't think MS Explorer had it.

Choice #3 stops sessions from working all the time.

What you really want is for your browser to accept all cookies
including persistent ones, but the cookie at the end of the session
regardless of the requested expiration date. Firefox can do that and
it's the setting that I use. I don't know if other browsers can do it yet.
 
B

bruno at modulix

Sullivan said:
I do not want to use Cookies in my site since not all web browser
support it well and sometimes people close cookie functioning for
security reasons.

Too bad for them. The only other way to support session is by encoding
the session id in the request, and it's much more of a security hole
than cookies.
I tried to add hidden field with a sessionID in every python CGI script
generated web pages, so everytime my client POST a request,

POST is for submitting data to the server. The method for retrieving
data from the server is GET.
the server
will retrieve the sessionID and decide if it is in the same session.
However, since python cgi do not have a function for redirecting to a
page, I use Location: url http head

How do you think redirections are implemented in frameworks that have
syntactic sugar for this ? At the HTTP level, redirections are done by
sending the corresponding status code and headers. And writing your own
redirect() function is pretty trivial.
or <body
onload="document.location=\'%s\'"></body> javascript for
redirecting.

And you don't want to use cookies ? Lol.
in this case, hidden field could not be used any more.

Really wish python would have session management or equivalent in
standard CGI module~~~~

*Please* take some time to understand how HTTP (and CGI) works - it will
save you a lot of time.

HTTP is a *stateless* protocol, which means that the server itself
forget everything about a request as soon as it is done handling it. So
a request must provide *all* necessary informations. The *only* way to
maintain some kind of 'session' with HTTP is to make sure the client
passes the needed session identifier back to the server. And the 2 only
ways to do it are to :
1/ use a cookie
2/ put the identifier in the request (usually in the query string part
of the url).

The fact that Python's CGI module doesn't offer out of the box support
for sessions has no relation with how sessions work.

BTW, you may want to have a look at Webstack, which provides a common
API over cgi, mod_python, and some other deployment solutions. This is a
pretty boring API (no magic, nothing fancy, nothing sexy etc), but it's
somewhat higher-level than plain CGI and it offers support for sessions
(yes, with cookies - like 99,99% of web programming solutions).
 
D

Dennis Lee Bieber

As you said, ....There is no solution? I mean, tracing a real session
without using tricks like hidden field and cookies in CGI script?
Dennis Lee Bieber ???
{Oh my... am I now an expert? <G>}

The entire basis of HTTP is that EVERY page request is independent
of any other. HTTP does not have "state" -- the server has no knowledge
of previous requests from any given TCP/IP address.

The only way to track a multi-page session requires either 1) a
cookie to be set on the first page access, and returned to the site on
all subsequent accesses (maybe with modification between pages), or 2)
embedding the equivalent of the cookie as a "hidden field" that is
returned either as part of a URL (is that a "GET" request) or as a field
("POST" request?).

Depending upon the implementation, those multiple pages might be
handled as cases within on CGI program (in which case the cookie/field
may indicate which "page" in the application is being processed and the
main URL is the same for all pages
"http://www.some.site/app.py/query-data-with-current-page) or each page
is a separate CGI program
("http://www.some.site/app_page1.py/query-data",
"http://www.some.site/app_page2.py/query-data")... It is quite likely
too, that much of the specific state is stored in a server-side
database, and the cookie/field is used as a key into the database. This
is how things like "shopping carts" would be handled, since you wouldn't
encode a full list of product/count into a single cookie.

--
 
D

Dennis Lee Bieber

Choice #2 stops the long-term tracking, but session cookies get
ignored if they have an expiration date (that makes them
non-ephemeral). That stops most session cookies from working. This
choice was available in some versions of Netscape Communicator but I
don't think MS Explorer had it.
Do we have the same dictionary?

Ephemeral, as in "mayflies are ephemeral", means "of short life"...
A cookie with a built-in expiration would, to my mind, be "ephemeral"
<G>

Firefox control has:

[] allow sites to set cookies
[] for originating site only
[] unless I have removed cookies set by the site
Keep cookies: until they expire
until I close Firefox
ask every time

(the "removed cookies" looks new -- Firefox 1.5.x had a major change in
options presentation)

I've seen similar options in browsers for quite some years now...
--
 
P

Paul Rubin

Dennis Lee Bieber said:
Do we have the same dictionary?

Ephemeral, as in "mayflies are ephemeral", means "of short life"...
A cookie with a built-in expiration would, to my mind, be "ephemeral"

Ephemeral cookies in web-head jargon are cookies with no specified
expiration date, so they go away when you close the browser. Cookies
with expiration dates persist until that date (which admittedly might
be just a few seconds away but usually is much longer) if the server
side programmer gets what s/he wants. Usually, the expiration date is
WAY in the future, i.e. the server is either trying to set a
persistent login credential (ok, if the user wants it) or is trying to
do invasive user tracking (not good: see the recent news stories about
the court case around the US government trying to get Google search
logs, and then remember that Google sets a cookie that tries to
correlate all of any user's searches with each other).
Firefox control has:

Keep cookies: until they expire
until I close Firefox

Yes, it took a very long time to get some browser to implement it.
There's a huge and hairy thread about it in bugzilla.mozilla.com
somewhere asking why Communicator didn't do it.
 
A

Aahz

Cookies aren't "tricks" -- they are THE standard, architected solution
for session persistence in HTTP 1.1 -- people who disable them are
saying they do not *WANT* persistent sessions... on their heads be it.

OTOH, there are too many sites out there that mandate persistent sessions
for no good reason. NetFlix being a canonical example (before logging
in, that is). Sites should degrade gracefully in the absence of cookies
unless they are absolutely essential for site operation.
 
I

I V

Sullivan said:
As you said, ....There is no solution? I mean, tracing a real session
without using tricks like hidden field and cookies in CGI script?

As people have said, this isn't a limitation of python, it's a feature
of HTTP. You might want to consider whether you actually need sessions
- see if you can design your application to use REST (see e.g.
http://www.xfront.com/REST-Web-Services.html , or there's lots of
information on Google).

People have also mentioned this in passing, but third alternative to
cookies and hidden fields is to use a session key in the query string -
this can be used for GET requests, so would work in redirects as well
as form submissions. Try:

http://yoursite.example/page?session=key

Then you need to remember, whenever you include a link to your site
that should retain the session information to add the session key to
the URL. You could define a function:

def session_url(url, key, **params={}):
qstring = "%s=%s" % ('session', urllib.quote(key))
for (name, value) in params.items():
qstring += "&%s=%s" %(urllib.quote(name), urllib.quote(value))
return qstring

And use it like:

#Do redirect
print "Location: " + session_url('new_page', session_key)

Or:

# Redirect to a page that loads the item called 'anitem'
print "Location: " + session_url('new_page', session_key, {'item',
'anitem'})

If you want to link to this URL in an HTML page, you need to remember
to escape the '&' character:

print "<a href='%s'>Edit item %s</a>" % (cgi.escape(session_url('edit',
session_key, {'item', item_name})), item_name)

Then, if you need to submit a form, you can add the key as a hidden
field.
 
A

Alex Martelli

Aahz said:
OTOH, there are too many sites out there that mandate persistent sessions
for no good reason. NetFlix being a canonical example (before logging
in, that is). Sites should degrade gracefully in the absence of cookies
unless they are absolutely essential for site operation.

I entirely agree with you -- do you mean netflix just won't work if I
try to visit it, not log in, with cookies disabled in my browser?!


Alex
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,995
Messages
2,570,230
Members
46,819
Latest member
masterdaster

Latest Threads

Top