Redirect To Login Page - Forms Authentication

D

Dave

Using Forms authentication. After a user successfully logs in, if they try
to access a page to which they have not been granted security, I expected an
error page to be displayed. Instead, the Login Form is redisplayed. I
thought the login page was only displayed if the user has not been
authenticated. Can someone please explain?
 
G

Gregory A. Beamer

Using Forms authentication. After a user successfully logs in, if
they try to access a page to which they have not been granted
security, I expected an error page to be displayed. Instead, the
Login Form is redisplayed. I thought the login page was only
displayed if the user has not been authenticated. Can someone please
explain?

The default implementation will redirect any time someone does not have
authorization, not whenever someone does not have authentication.

NOTE:
Authentication is verification of who a person is.
Authorization is whether the person is allowed to see something.

Once again, redirect to login is based on authorization. Login is an
authentication method.

If you want something other than the default, you will have to write it
into the authentication mechanism.
 
D

Dave

Thanks for the quick reply and for your insight. Unfortunately, I've not yet
reached the same conclusion.

For example, if a user has not been authenticated and the deny="?" is set,
the login screen will appear. In other words, the login screen is issued
because the user isn't authenticated. (It has nothing to do with his/her
authority?)

Secondly, if the user does not have authority, what possible good can result
from forcing them to login again? (If they didn't have authority before,
logging them in again isn't going to change anything.) To make matters
worse, the login screen now has a returnUrl to a screen to which the user
does not have authority. So, even if the user enters a valid
userid/password, a vicious circle occurs because they will be directed to a
screen to which they don't have access which will cause the Login screen to
appear... Surely, throwing an error would be a more sensible solution than
the Login screen vicious circle?

Finally, other web postings indicate the "Access is denied because of the
Web server's configuration. Contact the Web server's administrator for help."
error is issued when a user does not have authority. That's the error I
want!
 
G

Gregory A. Beamer

Thanks for the quick reply and for your insight. Unfortunately, I've
not yet reached the same conclusion.

This is because of appearances. BTW, before reading this, I have a more
complete example on my blog - http://snurl.com/mdbhl

I have used your post (anonymously) in the entry, as this is a common
topic.
For example, if a user has not been authenticated and the deny="?" is
set, the login screen will appear. In other words, the login screen
is issued because the user isn't authenticated. (It has nothing to do
with his/her authority?)

What is actually going on is the user makes a request and is assigned an
anonymous token. In other words, he is authenticated as anonymous.

If the page allows anonymous access, nothing happens. If he is not allow
access, he is prompted to log in.
Secondly, if the user does not have authority, what possible good can
result from forcing them to login again?

Possibly he has more than one login (bad form, but it happens all the time
in windows proper and very often in SQL Server (SQL Authentication)).

But, it is more an artifact of the IIS/ASP.NET authentication model.

Underneath the hood, the user is tied to the ASP.NET account for windows
access. The exception is windows authentication in ASP.NET, where the user
with the anonymous token is forced to log into windows to gain access. Then
he has his own domain account to use web resources. This is more applicable
to Intranet applications.

When a user hits the site, he has the anonymous token, which he can use as
long as it has rights. He then is forced to log in with an account. He can
use this until he hits a resource to which he has no rights. He is then
asked to log in again. It may not seem optimal, but there are few ways to
solve the authentication/authorization model, due to the fact the user is
ALWAYS authenticated, even if he is just authenticated as "anonymous".
(If they didn't have
authority before, logging them in again isn't going to change
anything.) To make matters worse, the login screen now has a
returnUrl to a screen to which the user does not have authority. So,
even if the user enters a valid userid/password, a vicious circle
occurs because they will be directed to a screen to which they don't
have access which will cause the Login screen to appear...

And this is precisely what happens.
Surely,
throwing an error would be a more sensible solution than the Login
screen vicious circle?

It would in some respects, but since the user is ALWAYS authenticated, even
if only as "anonymous", there is no easy way to distinguish one
authentication from another. If we say "if user is using the anonymous
token and does not have rights, force login, but if user is not using the
anonymous token and does not have rights, error out". This creates a bit
more complexity underneath the hood. And, there are times when you would
want it to always work the current default way (admitedly less than the
scenario you suggest).

Perhaps one day Micrsoft will allow the default to be set so you can choose
"only log in if anon token" or "always ask for login". It is not the case
today.
Finally, other web postings indicate the "Access is denied because of
the Web server's configuration. Contact the Web server's administrator
for help." error is issued when a user does not have authority.
That's the error I want!

That happens due to windows authorization issues and not ASP.NET
authorization issues. You can get this error by setting the rights on the
resource in windows, but it will deny all users, as all users,
authenticated in ASP.NET or not, use the ASP.NET token for windows access.

I have some suggestions on hiding links the user cannot see, creating views
for logged in users, etc. in the blog entry:
http://snurl.com/mdbhl
 
D

Dave

Many thanks!

Gregory A. Beamer said:
This is because of appearances. BTW, before reading this, I have a more
complete example on my blog - http://snurl.com/mdbhl

I have used your post (anonymously) in the entry, as this is a common
topic.


What is actually going on is the user makes a request and is assigned an
anonymous token. In other words, he is authenticated as anonymous.

If the page allows anonymous access, nothing happens. If he is not allow
access, he is prompted to log in.


Possibly he has more than one login (bad form, but it happens all the time
in windows proper and very often in SQL Server (SQL Authentication)).

But, it is more an artifact of the IIS/ASP.NET authentication model.

Underneath the hood, the user is tied to the ASP.NET account for windows
access. The exception is windows authentication in ASP.NET, where the user
with the anonymous token is forced to log into windows to gain access. Then
he has his own domain account to use web resources. This is more applicable
to Intranet applications.

When a user hits the site, he has the anonymous token, which he can use as
long as it has rights. He then is forced to log in with an account. He can
use this until he hits a resource to which he has no rights. He is then
asked to log in again. It may not seem optimal, but there are few ways to
solve the authentication/authorization model, due to the fact the user is
ALWAYS authenticated, even if he is just authenticated as "anonymous".


And this is precisely what happens.


It would in some respects, but since the user is ALWAYS authenticated, even
if only as "anonymous", there is no easy way to distinguish one
authentication from another. If we say "if user is using the anonymous
token and does not have rights, force login, but if user is not using the
anonymous token and does not have rights, error out". This creates a bit
more complexity underneath the hood. And, there are times when you would
want it to always work the current default way (admitedly less than the
scenario you suggest).

Perhaps one day Micrsoft will allow the default to be set so you can choose
"only log in if anon token" or "always ask for login". It is not the case
today.


That happens due to windows authorization issues and not ASP.NET
authorization issues. You can get this error by setting the rights on the
resource in windows, but it will deny all users, as all users,
authenticated in ASP.NET or not, use the ASP.NET token for windows access.

I have some suggestions on hiding links the user cannot see, creating views
for logged in users, etc. in the blog entry:
http://snurl.com/mdbhl
 

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

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top