By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,426 Members | 3,338 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,426 IT Pros & Developers. It's quick & easy.

Login page & Session data...response.redirect, server.transfer or ???

P: n/a
I've got an page (LOGIN.ASPX) that receives the user's login
information. During the page load, it checks the credentials against a
database and, if validation is successful, creates an instance of an
object that stores the user's basic profile data (username, user type,
associated sales region, etc.).

I've been taking this user info and placing it in the Session object
like so...

Session["USER"] = user;
Originally, I'd been trying to use Response.Redirect to send the users
to the next appropriate page in the application but it seems that the
Redirect kills the current thread and thus the session data is lost.

So I tried using Server.Transfer which seems to work but, of course,
the client's browser still shows "LOGIN.ASPX" in the address field. Not
really a problem except for two things...

.....when the user hits F5 to refresh the page, the page executes from
the beginning and walks through the login process all over again.

....,if the page displays a link to another page in the same
application, clicking the link will also cause the contents of the
Session object to disappear.
My questions are:

1.) Is there any way to use Redirect from the login page without losing
the contents of the Session object?

2.) Is there a more effective/efficient way to use Server.Transfer?

Any assistance would be greatly appreciated! Thanks!

Nov 19 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Have you tried using User.Identity.Name to identify the user? This may be a
more efficient method of doing this.

"GreggTB" wrote:
I've got an page (LOGIN.ASPX) that receives the user's login
information. During the page load, it checks the credentials against a
database and, if validation is successful, creates an instance of an
object that stores the user's basic profile data (username, user type,
associated sales region, etc.).

I've been taking this user info and placing it in the Session object
like so...

Session["USER"] = user;
Originally, I'd been trying to use Response.Redirect to send the users
to the next appropriate page in the application but it seems that the
Redirect kills the current thread and thus the session data is lost.

So I tried using Server.Transfer which seems to work but, of course,
the client's browser still shows "LOGIN.ASPX" in the address field. Not
really a problem except for two things...

.....when the user hits F5 to refresh the page, the page executes from
the beginning and walks through the login process all over again.

....,if the page displays a link to another page in the same
application, clicking the link will also cause the contents of the
Session object to disappear.
My questions are:

1.) Is there any way to use Redirect from the login page without losing
the contents of the Session object?

2.) Is there a more effective/efficient way to use Server.Transfer?

Any assistance would be greatly appreciated! Thanks!

Nov 19 '05 #2

P: n/a
Thanks for the suggestion, MrMike!

The user profile I'm trying to save is rather more complex than the
generic GenericPrincipal and GenericIdentity objects. It has a few more
string properties plus a small collection of sub-profile objects. The
app is still very early in development so I suppose I could try
reworking the user profile structure, extending IPrincipal and
IIdentity and storing the info that way.

Do you know if I can then use Response.Redirect without losing the data
or is there still a risk of that?

Nov 19 '05 #3

P: n/a
Here is one way to handle this:
So you need to use Forms Authentication to authenticate a given UID and
PWD
combination. These values can be in your DB and you need to look them up
and
verify that the typped in values match the ones in the DB. (Note that the
connection string for your DB has nothing to do with this. You use those
credentials to make the connection and take advantage of the connection
pool. You do NOT vary the conenct string with each user as this is a true
scalabilit killer.)

Sample code requires you to have a login method on your Principal class
(which calls your Identity class).

mUser.Login(txtUserId.Text, txtPassword.Text)
mUser = CType(Thread.CurrentPrincipal, myUser)

If mUser.Identity.IsAuthenticated = True Then
HttpContext.Current.User = mUser
Session("myPrincipal") = mUser

Web.Security.FormsAuthentication.RedirectFromLogin Page(txtUserId.Text,
False)
Else
'do something else
End If
I use code like this in my Global.asax file to re-use the principal value
on
each hit:

Private Sub Global_AcquireRequestState(ByVal sender As Object, ByVal e
As
System.EventArgs) Handles MyBase.AcquireRequestState

If Not Session("myPrincipal") Is Nothing Then
Thread.CurrentPrincipal = DirectCast(Session("myPrincipal"),
myUser)
HttpContext.Current.User =DirectCast(Session("myPrincipal"),
myUser)
Else
If Thread.CurrentPrincipal.Identity.IsAuthenticated = True Then
Web.Security.FormsAuthentication.SignOut()
Server.Transfer(Request.ApplicationPath + "/Login.aspx")
End If
End If

End Sub

Rocky Lhotka explains these concepts very well in his book on Business
Objects.
http://www.lhotka.net/ArticleIndex.a...ea=CSLA%20.NET

--
Joe Fallon


"GreggTB" <br********@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com... I've got an page (LOGIN.ASPX) that receives the user's login
information. During the page load, it checks the credentials against a
database and, if validation is successful, creates an instance of an
object that stores the user's basic profile data (username, user type,
associated sales region, etc.).

I've been taking this user info and placing it in the Session object
like so...

Session["USER"] = user;
Originally, I'd been trying to use Response.Redirect to send the users
to the next appropriate page in the application but it seems that the
Redirect kills the current thread and thus the session data is lost.

So I tried using Server.Transfer which seems to work but, of course,
the client's browser still shows "LOGIN.ASPX" in the address field. Not
really a problem except for two things...

....when the user hits F5 to refresh the page, the page executes from
the beginning and walks through the login process all over again.

...,if the page displays a link to another page in the same
application, clicking the link will also cause the contents of the
Session object to disappear.
My questions are:

1.) Is there any way to use Redirect from the login page without losing
the contents of the Session object?

2.) Is there a more effective/efficient way to use Server.Transfer?

Any assistance would be greatly appreciated! Thanks!

Nov 19 '05 #4

P: n/a
It may very well be a good book on Business Objects but the author
appears to be using an architectural design framework of his own
creation....maybe it's great but I cannot believe that the only way to
make this stuff work in .NET is to use this guy's framework. This has
to be a fairly common problem that can be handled without having to
learn some third-party design structure.

Nov 19 '05 #5

P: n/a
Ummm.
I think you missed the point completely.
There is no need to read the book or learn his framework.
(You would be better off if you did but that is another story.)

The code you are looking for was in my message:

Private Sub Global_AcquireRequestState(ByVal sender As Object, ByVal e As
System.EventArgs) Handles MyBase.AcquireRequestState

If Not Session("myPrincipal") Is Nothing Then
Thread.CurrentPrincipal = DirectCast(Session("myPrincipal"), myUser)
HttpContext.Current.User =DirectCast(Session("myPrincipal"), myUser)
Else
If Thread.CurrentPrincipal.Identity.IsAuthenticated = True Then
Web.Security.FormsAuthentication.SignOut()
Server.Transfer(Request.ApplicationPath + "/Login.aspx")
End If
End If

End Sub
--
Joe Fallon

"GreggTB" <br********@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
It may very well be a good book on Business Objects but the author
appears to be using an architectural design framework of his own
creation....maybe it's great but I cannot believe that the only way to
make this stuff work in .NET is to use this guy's framework. This has
to be a fairly common problem that can be handled without having to
learn some third-party design structure.

Nov 19 '05 #6

P: n/a
Okay, sorry about that. I've no doubt I did miss the point completely.
I was still losing all of the Session info with the Response.Redirect's
[endResponse] parameter set to [false]....I ended up just starting a
fresh web app and it's going well now. I'll try your suggestions and
I'm sure they'll work out.

Thanks for your help...and your patience!

Nov 19 '05 #7

P: n/a

GreggTB wrote:
I've got an page (LOGIN.ASPX) that receives the user's login
information. During the page load, it checks the credentials against a database and, if validation is successful, creates an instance of an
object that stores the user's basic profile data (username, user type, associated sales region, etc.).

I've been taking this user info and placing it in the Session object
like so...

Session["USER"] = user;
Originally, I'd been trying to use Response.Redirect to send the users to the next appropriate page in the application but it seems that the
Redirect kills the current thread and thus the session data is lost.

So I tried using Server.Transfer which seems to work but, of course,
the client's browser still shows "LOGIN.ASPX" in the address field. Not really a problem except for two things...

....when the user hits F5 to refresh the page, the page executes from
the beginning and walks through the login process all over again.

...,if the page displays a link to another page in the same
application, clicking the link will also cause the contents of the
Session object to disappear.
My questions are:

1.) Is there any way to use Redirect from the login page without losing the contents of the Session object?

I've got a forty page app at the moment using Response.Redirect on
practically every page, and heavily using the session.

Two ways you *might* be losing your session would be:
1) You're using cookieless session and you're redirecting to a complete
URL e.g. Response.Redirect("http://www.mysite.com/page.aspx") would
cause the session to be reinitialised (for cookieless session)

2) You're going into a subdirectory/virtual directory which has a
seperate application configured in IIS.

Any help?

Damien

Nov 19 '05 #8

P: n/a
I have no clue what was causing it but it certainly wasn't either of
those. I fiddled around for a while and eventually got things rolling
along just fine.

I'm being very careful to set the endResponse parameter to "true"...

Response.Redirect("goto.aspx", true);

....and that seems to be working fine. Dunno why I couldn't get it to
save originally. [shrug]

I do appreciate your help, though. Thanks!

Nov 19 '05 #9

P: n/a
Okay...I'm just way too tired. The above reply should say...

/**************************************************/
I'm being very careful to set the endResponse parameter to FALSE...

Response.Redirect("goto.aspx", false);
/**************************************************/

Obviously setting it to true will abort the thread and the Session data
will be lost.

Nov 19 '05 #10

P: n/a

GreggTB wrote:
Okay...I'm just way too tired. The above reply should say...

/**************************************************/
I'm being very careful to set the endResponse parameter to FALSE...

Response.Redirect("goto.aspx", false);
/**************************************************/

Obviously setting it to true will abort the thread and the Session data will be lost.


Hmm. I've never had that problem? Unless you're trying to save the
session data after the call to Response.Redirect, which as you say,
wont work since the thread gets killed.

I cant really think of anything else at the moment though. Glad you've
managed to find a solution.

Nov 19 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.