Forms Authentication without Login Page

[Paul Hodgson]

Is there any way to log someone in using Forms authentication *without*
using RedirectFromLoginPage()?

My reason for asking is that I'm trying to use Forms Authentication to allow
users to login to a site, but I keep coming up against the problem that all
the MS examples show using a Login page that users are redirected to if they
try to access a protected page. Trouble is - our site doesn't really have
protected pages. Any page is accessible to anyone - but if you're not logged
in then the page will show different information from what it will show if
you are logged in. Also, we don't want a separate login page, instead we
want users to be able to login inline with small forms inside other pages.

What this means I think is that I need to be able to do the following
whenever a page is loaded:
1. Check explicitly if the user has been logged in using Forms
Authentication so the code can decide what to display.
2. If appropriate, explicitly log the user in but without redirecting to
anywhere else (if the user has just posted back to the page by filling in a
Login form).

Any pointers on how to do that appreciated

 

[Brad]

If I read your questions correctly, the quick answer is yes, you can do
exactly want your asking.
All you have to do is create the forms authentication ticket yourself when
the user logs in using your login dialog.

Here's an example of what you'd need to do:

Create a web user control which contains your sign-in dialog; a couple of
text boxes for name and password and perhaps a result label to display if
the login was incorrect. Code behind for this control would validate the
user and password, i.e. check them against a database. Then the code sets
the authentication cookie. i.e (very simple).
FormsAuthentication.SetAuthCookie(UserName.Text, False)

Include above web control in your page(s). Obviously you don't want to show
this login dialog if they are already logged in so you can just put code in
the above user control to hide itself or in the page(s) to hide the control.
i.e. (in the above user control)
Me.Visible = Request.IsAuthenticated = False

As for what you show in your pages you can simply test like the following
If Request.IsAuthenticated Then
' do stuff to show my authorized content
Else
' do stuff to show my unauthorized content
End If

Some references on this.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetch08.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT03.asp


Hope this helps some


Brad

 

[Paul Hodgson]

Thanks Brad! That's very useful and *almost* does what I want. The only
problem is that by doing it that way,
the authentication seems to be delayed by one page view: In other words, I
hit Login in my login control. The code works, and my login control calls
FormsAuthentication.SetAuthCookie() from the Page_Load() function. The
trouble is, by that point it's too late: Lots of my other controls have
already executed Page_Load, displaying their contents on the assumption that
we are not logged in. Even worse, even *after* calling SetAuthCookie(),
my login control still doesn't seem to realise that it's now logged in.
Request.IsAuthenticated still returns false. I'm guessing it's dependent on
having actually read in the cookie from the request. Of course if I hit
Refresh in the browser, or click on a link to go to another page, then it
all works.

Is there any way to make sure that the action of servicing any login request
is the first thing the page does, before any of the controls on the page
execute Page_Load()? (I guess if I can do that, I can at least then set some
static member of some class to say that we are now authenticated, to get
round the problem that Request.Authenticated is returning false).

Paul

--

 

[MSFT]

Hi Paul,

Instead of set static member, you may consider set a session variant to
indicate if a user is authenticated or not.

Luke
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Brad]

In my login control I set the authentication ticket and then immediately
issue a Response.Redirect(Request.Url.AbsoluteUri)
This forces the page to redirect back to itself and on *that* request the
Request.IsAuthenticated will be true for the entire request context.

Brad

 

[Paul Hodgson]

OK thanks Brad. That's definitely one way of doing it - though in my case,
for performance reasons I think I'd avoid that approach: (Constructing some
pages takes a lot of work, including a couple of heavy database queries,
which I wouldn't really want to have done before discovering that the user
has just logged in and we need to redirect). In the end the way I solved it
was by this:
I have all my .aspx pages derived from a common base class. The Page_Load
handler to this base class checks to see we have just posted back by
pressing a login button. If so then it identifies the login control and
invokes methods on the control to do the login. A bit messy but it seems to
work and AFAICS it ensures that the correct login status is establish prior
to any substantial page load processing.

Paul

--