CAPTCHA (verification code) and session

[sb5309]

When one uses CAPTCHA (form with verification code), a session is
required to keep the session data.

In examples that I have seen on the net, I did not see a session is
closed after use.

Imagine a case when someone gets to a form with CAPTCHA, a session
will be started in the server; and then the person decides to jump to
another site without filling the form. The session data still exists
in the server. If this scenario gets repeated many times in a day,
will the server be overly-burdened with session data or crash ?

There are loads of material on the net; I figure I need to take a long
long time wading through them to get the answer.

Any tips appreciated. Thanks.

[rf]

<sb****@yahoo.comwrote in message
news:ff**********************************@a18g2000 pra.googlegroups.com...

When one uses CAPTCHA (form with verification code), a session is
required to keep the session data.

In examples that I have seen on the net, I did not see a session is
closed after use.

Imagine a case when someone gets to a form with CAPTCHA, a session
will be started in the server; and then the person decides to jump to
another site without filling the form. The session data still exists
in the server. If this scenario gets repeated many times in a day,
will the server be overly-burdened with session data or crash ?

The session will expire after a suitable time. Normal periodic cleanup will
then delete the session data.

And no, there is no way at all to know that a viewer has navigated away from
the site so there is not way to know to mmediately close the session. That
is why sessions expire after a suitable time.

CRAPTCHA's have nothing to do with the matter.

[Gordon Burditt]

>When one uses CAPTCHA (form with verification code), a session is

>required to keep the session data.

In examples that I have seen on the net, I did not see a session is
closed after use.

Users cannot be forced to press a "LOGOUT" button, and often the
session is going to be used further: CAPTCHAs generally protect
forms, and the session may be needed for the form, especially if
it is multi-page, so deleting the session on verification of the
CAPTCHA is too soon. In the implementation of many "login" schemes,
the session is needed until the user intends to leave.

>Imagine a case when someone gets to a form with CAPTCHA, a session
will be started in the server; and then the person decides to jump to
another site without filling the form. The session data still exists
in the server. If this scenario gets repeated many times in a day,
will the server be overly-burdened with session data or crash ?

A server that has problems here is pretty fragile. You can expire
old sessions after a reasonable time (does a user need more than
an hour to sign up for a mailing list?). The only halfway excuse
for a "crash" is that the server runs out of disk space, and that's
just poor planning. If a server is getting 100 sessions a second
for a week, with 100 bytes of session data per session, that's only
6GB, if for some reason sessions have to last a week.

It's possible to put session data into a database table, using
session handlers. A 6GB table should be handled easily. 60 million
small session files in a single UNIX directory are probably going
to cause a serious performance problem.

[sb5309]

The session will expire after a suitable time. Normal periodic cleanup will
then delete the session data.

Does it mean that if some gets to page with CAPTCHA, but does not fill
up the form till, say, 3 hours later (may be he has to go out), the
session data will no longer be valid ?

>
And no, there is no way at all to know that a viewer has navigated away from
the site so there is not way to know to mmediately close the session. That
is why sessions expire after a suitable time.

CRAPTCHA's have nothing to do with the matter.

[rf]

<sb****@yahoo.comwrote in message
news:e2**********************************@a19g2000 pra.googlegroups.com...

>

>The session will expire after a suitable time. Normal periodic cleanup
will
then delete the session data.

Does it mean that if some gets to page with CAPTCHA, but does not fill
up the form till, say, 3 hours later (may be he has to go out), the
session data will no longer be valid ?

Yes. That is what expiring the session means. The session no longer exists.
You have to "log in" again.

Try it and see somewhere, or do you *always* "logout" from such places?

Once again CRAPTCHA's have nothing specifically to do with this. They merely
make almost (and sometimes not) visible one more piece of data (after userid
and password) that must be entered into the "login" form.
Hang on, I just re-read your posts with a different slant, the key being
"without filling the form".

You arrive at a form (with or without a CRAPTCHA). The session is only
established *after* you have completed and submitted the form. If you simply
navigate elsewhere than any well designed server side script will not have
set up a session yet. Part of setting up the session is processing the data
on the login form.

Not that it matters anyway, it will be expired after a suitable time anyway.

[Gordon Burditt]

>The session will expire after a suitable time. Normal periodic cleanup will

>then delete the session data.

Does it mean that if some gets to page with CAPTCHA, but does not fill
up the form till, say, 3 hours later (may be he has to go out), the
session data will no longer be valid ?

Yes, same as a page without a CAPTCHA but which requires a login.
This is an issue with sessions, not CAPTCHAs. Dialup internet
sessions will probably disconnect if the connection is idle for
a much shorter time than that.

I don't see this as a problem for a CAPTCHA protecting a form to
sign up for a mailing list, which really ought to be doable in 2
minutes of full attention by a one-finger typist (the whole signup
procedure, not just the CAPTCHA). You solve the CAPTCHA, enter
your email address (twice), check off which mailing list(s) you
want to subscribe to, and click SUBMIT (possibly on several pages).
If your session times out, go back and try again. How much time
did you lose? 1 minute?

What is a "suitable time" varies. If you're expected to enter a
detailed customer service complaint or a 100-question survey, three
hours or even two days while you go find the invoice numbers and
serial numbers may be unreasonable. It's up to the person writing
the pages.

Note that it's possible to renew the session every time you submit
a form, so that 100-question survey might require you to fill out
5 questions on a page and hit SUBMIT within 3 hours, and then you
can have up to 3 hours on the next set of 5 questions.
This reminds me of a discussion long, long ago about timing out
(and then rejecting) print spool jobs after a certain period of
time if the printer went not ready for a while - which usually meant
that no one changed the paper. Someone wanted to have a fairly
short timeout like 5 minutes, which was a problem since no one was
actually watching the printer except perhaps the guy wanting his
output, and sometimes the stack of paper boxes ran out and we needed
some from another floor. I wanted the timeout to at least cover
the time to get a service tech out for the printer to declare it
DOA, the time to approve a Capital Equipment Request for a new
printer, plus the time to backorder the new printer and have it
shipped here and installed: at least a year (in some ways this was
a dig at the bureaucracy at that employer). (Manual cancellation
of print jobs by administrators or the user who submitted them was
possible if it was needed.)

[Geoff Berrow]

Message-ID: <2K******************************@posted.interneta merica>
from Gordon Burditt contained the following:

>What is a "suitable time" varies. If you're expected to enter a
detailed customer service complaint or a 100-question survey, three
hours or even two days while you go find the invoice numbers and
serial numbers may be unreasonable. It's up to the person writing
the pages.

I've had a slight problem with sessions expiring with an abstract
submission system where some users have been composing their abstracts
using the online form. What would be the best solution do you think?
Cookies?
--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
http://slipperyhill.co.uk - http://4theweb.co.uk

[Gordon Burditt]

>>What is a "suitable time" varies. If you're expected to enter a

>>detailed customer service complaint or a 100-question survey, three
hours or even two days while you go find the invoice numbers and
serial numbers may be unreasonable. It's up to the person writing
the pages.

I've had a slight problem with sessions expiring with an abstract
submission system where some users have been composing their abstracts
using the online form. What would be the best solution do you think?

First, state the problem: How long is the current expiration time?
What time are the users complaining is too short?

You can set the expiration time of sessions (although this may be
problematical on shared hosted systems with an uncooperative
administration, in which case my advice is to change hosts). Is
the actual expiration shorter than what you expect, or is it just
that you don't want to set it longer? If you don't want to set it
longer, why?

>Cookies?

[Geoff Berrow]

Message-ID: <DJ******************************@posted.interneta merica>
from Gordon Burditt contained the following:

>First, state the problem:

OK, we have a form which users use to fill in an abstract for an
academic paper. Most people use it ok, but occasionally a user logs in,
opens the form and then fills it in over a long period of time, during
which the session expires.

>How long is the current expiration time?
What time are the users complaining is too short?

You can set the expiration time of sessions (although this may be
problematical on shared hosted systems with an uncooperative
administration, in which case my advice is to change hosts). Is
the actual expiration shorter than what you expect, or is it just
that you don't want to set it longer? If you don't want to set it
longer, why?

For the most part, the session timeout is fine. I suppose I could save
the output of the form temporarily if the session has timed out and then
write it to the database once the user re-submits their login details,
unless anyone has any better ideas?
--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
http://slipperyhill.co.uk - http://4theweb.co.uk

[Jerry Stuckle]

rf wrote:

<sb****@yahoo.comwrote in message
news:e2**********************************@a19g2000 pra.googlegroups.com...

>>The session will expire after a suitable time. Normal periodic cleanup
will
then delete the session data.

Does it mean that if some gets to page with CAPTCHA, but does not fill
up the form till, say, 3 hours later (may be he has to go out), the
session data will no longer be valid ?

Yes. That is what expiring the session means. The session no longer exists.
You have to "log in" again.

Try it and see somewhere, or do you *always* "logout" from such places?

Once again CRAPTCHA's have nothing specifically to do with this. They merely
make almost (and sometimes not) visible one more piece of data (after userid
and password) that must be entered into the "login" form.
Hang on, I just re-read your posts with a different slant, the key being
"without filling the form".

You arrive at a form (with or without a CRAPTCHA). The session is only
established *after* you have completed and submitted the form. If you simply
navigate elsewhere than any well designed server side script will not have
set up a session yet. Part of setting up the session is processing the data
on the login form.

Not that it matters anyway, it will be expired after a suitable time anyway.

Incorrect. The session is established on the page showing the CAPTCHA
image (if not before). It is needed to pass the CAPTCHA key to the next
page securely.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[rf]

"Geoff Berrow" <bl******@ckdog.co.ukwrote in message
news:71********************************@4ax.com...

Message-ID: <DJ******************************@posted.interneta merica>
from Gordon Burditt contained the following:

>>First, state the problem:

OK, we have a form which users use to fill in an abstract for an
academic paper. Most people use it ok, but occasionally a user logs in,
opens the form and then fills it in over a long period of time, during
which the session expires.

Ah, so we get finally to the actual problem.

It's a user problem. Your user starts filling in a form, any form, the user
walks away, the form times out (the session expires). That is how it works.

So tell your users right up front on the top of the form in big bright
letters that they only have a certain amount of [time] to fill in the form.
Replace [time] with whatever you feel comfortable with and set your session
timeout accordingly.
Better yet, for such a potentialy long time thing you might re-think your
strategy. Why not ask them to prepare, carefully, a text document and when
it is finished upload it?

And what was it with that distracting side issue with CRAPTCHAs?

[rf]

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:gd**********@registered.motzarella.org...

rf wrote:

>You arrive at a form (with or without a CRAPTCHA). The session is only
established *after* you have completed and submitted the form. If you
simply navigate elsewhere than any well designed server side script will
not have set up a session yet. Part of setting up the session is
processing the data on the login form.

Incorrect. The session is established on the page showing the CAPTCHA
image (if not before). It is needed to pass the CAPTCHA key to the next
page securely.

Yes, of course, My bad.

I don't use the damn things so had not thought it through complely.

Nevertheless the OP should not be concerned about such abandoned sessions.

[Captain Paralytic]

On 20 Oct, 12:34, "rf" <[e-mail]:

"Geoff Berrow" <[e-mail] in message
And what was it with that distracting side issue with CRAPTCHAs?

That was a different poster!

[Jerry Stuckle]

rf wrote:

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:gd**********@registered.motzarella.org...

>rf wrote:

>>You arrive at a form (with or without a CRAPTCHA). The session is only
established *after* you have completed and submitted the form. If you
simply navigate elsewhere than any well designed server side script will
not have set up a session yet. Part of setting up the session is
processing the data on the login form.

>Incorrect. The session is established on the page showing the CAPTCHA
image (if not before). It is needed to pass the CAPTCHA key to the next
page securely.

Yes, of course, My bad.

I don't use the damn things so had not thought it through complely.

Nevertheless the OP should not be concerned about such abandoned sessions.

Agreed.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[C. (http://symcbean.blogspot.com/)]

On 20 Oct, 07:05, [e-mail] wrote:

When one uses CAPTCHA (form with verification code), a session is
required to keep the session data.

In examples that I have seen on the net, I did not see a session is
closed after use.

Imagine a case when someone gets to a form with CAPTCHA, a session
will be started in the server; and then the person decides to jump to
another site without filling the form. The session data still exists
in the server. If this scenario gets repeated many times in a day,
will the server be overly-burdened with session data or crash ?

There are loads of material on the net; I figure I need to take a long
long time wading through them to get the answer.

Any tips appreciated. Thanks.

As others have pointed out, its unlikely to be a problem unless you're
getting huge volumes of traffic.

The session is just one place to store the details for reconciliation.
Another way would be to pass the the capcha string to the browser and
back AES encrypted in a hidden field and require the decrypted version
to match the input - but you'd need to add additional controls to
prevent replay attacks.

C.

[Geoff Berrow]

Message-ID: <y1*****************@news-server.bigpond.net.aufrom rf
contained the following:

>OK, we have a form which users use to fill in an abstract for an
academic paper. Most people use it ok, but occasionally a user logs in,
opens the form and then fills it in over a long period of time, during
which the session expires.

Ah, so we get finally to the actual problem.

It's a user problem. Your user starts filling in a form, any form, the user
walks away, the form times out (the session expires). That is how it works.

So tell your users right up front on the top of the form in big bright
letters that they only have a certain amount of [time] to fill in the form.
Replace [time] with whatever you feel comfortable with and set your session
timeout accordingly.
Better yet, for such a potentialy long time thing you might re-think your
strategy. Why not ask them to prepare, carefully, a text document and when
it is finished upload it?

Read something?

These are highly educated academics, researchers. phds and professors.
Believe me, we need to make it especially idiot proof.

I think your solution avoids the problem.
--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
http://slipperyhill.co.uk - http://4theweb.co.uk