M
Mike Kingscott
Hi there,
I've been doing some asp.net coding (finally), and I've created an app
that takes in some data, validates it, performs a calculation and
writes it to a db. My intention is to use Forms Authentication so that
surfers have to enter an id (and only an id) in order to move around
the site. Folder structure is thus:
Broker (top level app folder, contains web.config, deny all unauth
users)
CP (Product Info folder, contains Apply Online aspx)
So, all well and good. I'll have my login page in the Broker folder,
and that will force anyone to login if they try to go to Broker or CP,
then redirect them to where they want to go.
But as usual, there's a kink in the line. In some cases, a single id
will not suffice, there needs to be an identifier and an id, meaning a
different login form, or altering the existing one. I could get the
people who require two ids to go directly to the login page, and pass
in a querystring parm that identifies that they are 'special', and
alter the form and code behind accordingly.
The question is, what then? I was thinking of storing their
authentication details in a cookie (as seems to be common practice),
utilising the user value part of the cookie to store details about
them - basically, the surfer is resolved down to an agent id (which is
good enough for 80% of the surfers), but the 'special' 20% need extra
info to be resolved to that agent id.
I could store the agent id in the User Name of the auth ticket, and
then the extra info about them in the User Data auth ticket (i.e. the
fact that they are 'special' and the required extra data).
The big problem is, what happens when the cookie expires? They will be
redirected to the login page (as they are no longer authenticated),
and the app will have lost site of the fact that they are 'special',
and present them with the standard login form. Could I store the fact
that they are special in ViewState? I don't want to use Session as
that will expire as well, same problem... I suppose I could set the
cookie to expire in 12 hours, giving them plenty of time to do their
work...
Also, am I right in believing that once you're authenticated, that's
it? I.e. the fact that some people are 'special' won't really matter
in the call to Application_AuthenticateRequest?
Ta all,
Mike K.
I've been doing some asp.net coding (finally), and I've created an app
that takes in some data, validates it, performs a calculation and
writes it to a db. My intention is to use Forms Authentication so that
surfers have to enter an id (and only an id) in order to move around
the site. Folder structure is thus:
Broker (top level app folder, contains web.config, deny all unauth
users)
CP (Product Info folder, contains Apply Online aspx)
So, all well and good. I'll have my login page in the Broker folder,
and that will force anyone to login if they try to go to Broker or CP,
then redirect them to where they want to go.
But as usual, there's a kink in the line. In some cases, a single id
will not suffice, there needs to be an identifier and an id, meaning a
different login form, or altering the existing one. I could get the
people who require two ids to go directly to the login page, and pass
in a querystring parm that identifies that they are 'special', and
alter the form and code behind accordingly.
The question is, what then? I was thinking of storing their
authentication details in a cookie (as seems to be common practice),
utilising the user value part of the cookie to store details about
them - basically, the surfer is resolved down to an agent id (which is
good enough for 80% of the surfers), but the 'special' 20% need extra
info to be resolved to that agent id.
I could store the agent id in the User Name of the auth ticket, and
then the extra info about them in the User Data auth ticket (i.e. the
fact that they are 'special' and the required extra data).
The big problem is, what happens when the cookie expires? They will be
redirected to the login page (as they are no longer authenticated),
and the app will have lost site of the fact that they are 'special',
and present them with the standard login form. Could I store the fact
that they are special in ViewState? I don't want to use Session as
that will expire as well, same problem... I suppose I could set the
cookie to expire in 12 hours, giving them plenty of time to do their
work...
Also, am I right in believing that once you're authenticated, that's
it? I.e. the fact that some people are 'special' won't really matter
in the call to Application_AuthenticateRequest?
Ta all,
Mike K.