Security via ASP & Access

M

Mike Mueller

I am using the standard approach to this, setting a session
variable for the authenticated users. All seems to work well
except for 1 machine, which always goes back to the login
form. The validation page seems to work fine, as it sends
an email to me which shows a successful login. I know this
is not an FP issue, but I am confident that someone here can
tell me where to start.

Mike
 
T

Thomas A. Rowe

Make sure cookies are enabled for the browser on the machine

--
==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
WEBMASTER Resources(tm)

FrontPage Resources, WebCircle, MS KB Quick Links, etc.
==============================================
 
J

Jon Spivey

Hi,
you'd probably want to present a message to the user that they have cookies
disabled, eg

<script type="text/javascript">
if(!document.cookie)alert("You don't have cookies");
</script>

At least they'll know its their browser setup and not your site to blame -
I'm assuming this user isn't going to change their browser setting just to
visit your site.

Jon
Microsoft MVP - FP
 
B

Bob

Hi,
you'd probably want to present a message to the user that they have cookies
disabled, eg

<script type="text/javascript">
if(!document.cookie)alert("You don't have cookies");
</script>

At least they'll know its their browser setup and not your site to blame -
I'm assuming this user isn't going to change their browser setting just to
visit your site.
Click to expand...

Hmm... I think you might want to pilot that code first.

Instead , send them a cookie on the initial page "a". Then try to
retrieve it on page "b". Not there ? The don't have cookie support.
Works very well with login schemes. If there is no cookie when they
arrive at page "b", take alternative action (i.e. "Hey dummy, you
didn't login... or your browser does not support cookies... blah,
blah, blah).

Editor's note: no cookie detection scheme is perfect, users can also
selectively reject cookies, delete cookies while running, etc. If
cookies are required for operation, you have to check existence each
time and be prepared for them disappearing at some point in the cycle.

Editor's note 2: No login scheme is ideal unless you use SSL
authentication. otherwise you will always have issues with some users.
 
J

Jon Spivey

Why? Every asp page sends a cookie to the client (the session id) with every
page request so if it isnt there - ie document.cookie is empty - we know
that cookies arent supported in the browser and can send a message

If we wanted to check if the user has dated cookies enabled (to cover the
case where a user blocks dated cookies but accepts session cookies) we'd do
soemthing like this

<%
response.cookies("name")="jon"
response.cookies("name").expires = now()+30
%>

<script type="text/javascript">
if(document.cookie.indexOf("name")<0)alert("you dont have cookies!");
</script>

Either way there's no need set and check on different pages - although of
course you could if you wanted.

Jon
Microsoft MVP - FP
 
B

Bob

Why? Every asp page sends a cookie to the client (the session id) with every
page request so if it isnt there - ie document.cookie is empty - we know
that cookies arent supported in the browser and can send a message
Click to expand...

"Why is it a bad idea?" ? Test that code and get back to me on that
issue.
If we wanted to check if the user has dated cookies enabled (to cover the
case where a user blocks dated cookies but accepts session cookies) we'd do
soemthing like this

<%
response.cookies("name")="jon"
response.cookies("name").expires = now()+30
%>

<script type="text/javascript">
if(document.cookie.indexOf("name")<0)alert("you dont have cookies!");
</script>
Click to expand...

I like your JS much better than the previous test. :)
Either way there's no need set and check on different pages - although of
course you could if you wanted.
Click to expand...

The reason to check on different pages is that I can do it all on the
server where I am sure that the code will run. A browser can support
cookies yet have JS shut off. By testing on the server we can avoid
that pothole. Of course, that requires multiple pages since we have to
throw the cookie on the first page... then test on the next cycle back
to the server.
 
Top