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

Persisting user login credentials across pages

P: n/a
Hi
What is the recommended way to store a user's database credentials across
the pages of a web application so that each time the database is accessed the
system doesn't have to ask them for their username and password again
We have previously stored these in a session variable (encrypted) and
retrieved from their - but are worried about the impact on performance if the
number of users increases.
Had thought about cookies but worried about security (even if details are
encrypted) and obviously ability of user to be able to delete etc.
Thanks in advance
siobhan
Nov 19 '05 #1
Share this Question
Share on Google+
19 Replies


P: n/a
Using the Sessions Object

Once they login successfully:

<SCRIPT runat="SERVER">

Sub Login_Click(obj as Object, e as EventArgs)
IF tbName.Value <> ""
Session("Name") = tbName.Value
Response.Write("Welcome" & Session("Name") & "!")
ELSE
Response.Write("You Did Not Log In!")
END IF
END Sub

</SCRIPT>

Nov 19 '05 #2

P: n/a
OR EVEN THIS:

Sub Login_Click(obj as Object, e as EventArgs)

IF Request("tbPassword") = "XXXX" THEN
Session("LoggedIn") = TRUE
Session("UserName") = Request.Form("tbUserName")
Server.Transfer("Session.aspx")
END IF

END Sub

Nov 19 '05 #3

P: n/a
What if there is a large number of users - will this affect performance, or
is this a small enough amoun tof information to get away with?
Thanks
"Sparky Arbuckle" wrote:
OR EVEN THIS:

Sub Login_Click(obj as Object, e as EventArgs)

IF Request("tbPassword") = "XXXX" THEN
Session("LoggedIn") = TRUE
Session("UserName") = Request.Form("tbUserName")
Server.Transfer("Session.aspx")
END IF

END Sub

Nov 19 '05 #4

P: n/a
Each user should have their own unique Session ID. Just make Session ID
equal to their usernames. There should only be one of each username
correct?

Nov 19 '05 #5

P: n/a
I am actually trying to persist their database username and password which
will be needed each time the user needs to access the database from any of
the pages so I can't use session id as a username
Cheers

"Sparky Arbuckle" wrote:
Each user should have their own unique Session ID. Just make Session ID
equal to their usernames. There should only be one of each username
correct?

Nov 19 '05 #6

P: n/a
Lookup forms authentication.
(http://samples.gotdotnet.com/quickstart/aspplus/). Basically, you
could keep track of a user's ID when he/she authenticated successfully.
By persisting this ID in an authentication cookie, you could access it
and get the user's information based on that ID.

Siobhan: This is ASP.NET, not ASP :). You are suggesting a solution
which implies a top-down ASP.NET model, which ASP.NET is not. Whenever
you directly access form variables, 9 out of the 10 cases there is a
better way. Controls are there to provide a level of abstraction and
make things easier and more convenient. In your case, some textboxes
would be more appropriate. They expose the posted value through a Text
property, which you can then access.
Anyway, I suggest you read about the concepts recommended in ASP.NET,
because it can help you a great deal.

HTH.

Nov 19 '05 #7

P: n/a
But I also need their database (SQL Server) password - without this I cannot
access the database.
Are you suggesting a user control which has text boxes to hold the username
and password which I place on all pages? I still have the issue of passing
the details bteween the pages then?
Sorry - quite new to ASP.Net in case you hadn't noticed and never did ASP so
its all new and bewildering!!

"Wilco Bauwer" wrote:
Lookup forms authentication.
(http://samples.gotdotnet.com/quickstart/aspplus/). Basically, you
could keep track of a user's ID when he/she authenticated successfully.
By persisting this ID in an authentication cookie, you could access it
and get the user's information based on that ID.

Siobhan: This is ASP.NET, not ASP :). You are suggesting a solution
which implies a top-down ASP.NET model, which ASP.NET is not. Whenever
you directly access form variables, 9 out of the 10 cases there is a
better way. Controls are there to provide a level of abstraction and
make things easier and more convenient. In your case, some textboxes
would be more appropriate. They expose the posted value through a Text
property, which you can then access.
Anyway, I suggest you read about the concepts recommended in ASP.NET,
because it can help you a great deal.

HTH.

Nov 19 '05 #8

P: n/a
Sorry, I meant Sparky Arbuckle.

Siohban: you can place those textboxes in a usercontrol, such as
Login.ascx. You can place this login control on a login page. If you
lookup how forms authentication works, it should be fairly
straightforward to figure out how to get information based on a user's
ID. Such a user ID can be persisted across pages (using sessions).

Nov 19 '05 #9

P: n/a
Sessions is a good start. Reading into Sessions Object you can even
preset the user's login and password into a Session Object that carries
with them across their web experience.

Nov 19 '05 #10

P: n/a
Hi
Yes this is what we have done before but we are passing the data using a
session variable and I had just been worried about the implications of this.
I am not sure how Forms authentication would work - the sample using
passwords on the site you recommended had passwords stored in the config file
- we are using SQL Server authentication to authenticate users. Or maybe I
am getting confused as to what you meant. I think I understand the concept
of setting the authorisation cookie etc, but I didn't know if this could be
used to store the password that they entered on the login page, or if it
could, would it be safe?
Thanks
Siobhan

"Wilco Bauwer" wrote:
Sorry, I meant Sparky Arbuckle.

Siohban: you can place those textboxes in a usercontrol, such as
Login.ascx. You can place this login control on a login page. If you
lookup how forms authentication works, it should be fairly
straightforward to figure out how to get information based on a user's
ID. Such a user ID can be persisted across pages (using sessions).

Nov 19 '05 #11

P: n/a
Siobhan,
In a large system the DB tends to be the bottleneck so you want to access it
only when truly needed.
You can always add more web servers to handle the load. Scaling the DB is
quite a bit trickier.

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


"Siobhan" <Si*****@discussions.microsoft.com> wrote in message
news:80**********************************@microsof t.com...
Hi
Yes this is what we have done before but we are passing the data using a
session variable and I had just been worried about the implications of
this.
I am not sure how Forms authentication would work - the sample using
passwords on the site you recommended had passwords stored in the config
file
- we are using SQL Server authentication to authenticate users. Or maybe
I
am getting confused as to what you meant. I think I understand the
concept
of setting the authorisation cookie etc, but I didn't know if this could
be
used to store the password that they entered on the login page, or if it
could, would it be safe?
Thanks
Siobhan

"Wilco Bauwer" wrote:
Sorry, I meant Sparky Arbuckle.

Siohban: you can place those textboxes in a usercontrol, such as
Login.ascx. You can place this login control on a login page. If you
lookup how forms authentication works, it should be fairly
straightforward to figure out how to get information based on a user's
ID. Such a user ID can be persisted across pages (using sessions).

Nov 19 '05 #12

P: n/a
Hi
The application we are writing is a database application in which each user
must have a unique SQL Server login to allow for auditing of certain
information. Most of the functions of the system are database driven so
database access is unavoidable. At this stage it won't be a large system but
I am just trying to get a handle of this for future developments.
Can I just ask about connection pooling, if each user has a different
username and password does this make the connection string different and
therefore each login won't use the pool?
Thanks
Siobhan

"Joe Fallon" wrote:
Siobhan,
In a large system the DB tends to be the bottleneck so you want to access it
only when truly needed.
You can always add more web servers to handle the load. Scaling the DB is
quite a bit trickier.

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


"Siobhan" <Si*****@discussions.microsoft.com> wrote in message
news:80**********************************@microsof t.com...
Hi
Yes this is what we have done before but we are passing the data using a
session variable and I had just been worried about the implications of
this.
I am not sure how Forms authentication would work - the sample using
passwords on the site you recommended had passwords stored in the config
file
- we are using SQL Server authentication to authenticate users. Or maybe
I
am getting confused as to what you meant. I think I understand the
concept
of setting the authorisation cookie etc, but I didn't know if this could
be
used to store the password that they entered on the login page, or if it
could, would it be safe?
Thanks
Siobhan

"Wilco Bauwer" wrote:
Sorry, I meant Sparky Arbuckle.

Siohban: you can place those textboxes in a usercontrol, such as
Login.ascx. You can place this login control on a login page. If you
lookup how forms authentication works, it should be fairly
straightforward to figure out how to get information based on a user's
ID. Such a user ID can be persisted across pages (using sessions).


Nov 19 '05 #13

P: n/a
In that case you won't be able to benefit from connection pooling. The logon
credentials have to match exactly for pooling. In general web apps don't lend
themselves too well for client/server apps kind of things. If you're worrying
about scalability you'll have to seriously reconsider if every user must have
it's own unique sql server login. Of course you could create a unique login
for every user but use a general account for all sql connections...

If you're worrying about storing passwords safely... Storing the passwords
in a Session object as it is is not exactly very safe. If you want you could
use the DPAPI library or the MS Encryption application block to encrypt
passwords before you store them in a Session object. Hth.

Kind regards,
Nikander & Margriet Bruggeman
"Siobhan" wrote:
Hi
The application we are writing is a database application in which each user
must have a unique SQL Server login to allow for auditing of certain
information. Most of the functions of the system are database driven so
database access is unavoidable. At this stage it won't be a large system but
I am just trying to get a handle of this for future developments.
Can I just ask about connection pooling, if each user has a different
username and password does this make the connection string different and
therefore each login won't use the pool?
Thanks
Siobhan

"Joe Fallon" wrote:
Siobhan,
In a large system the DB tends to be the bottleneck so you want to access it
only when truly needed.
You can always add more web servers to handle the load. Scaling the DB is
quite a bit trickier.

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


"Siobhan" <Si*****@discussions.microsoft.com> wrote in message
news:80**********************************@microsof t.com...
Hi
Yes this is what we have done before but we are passing the data using a
session variable and I had just been worried about the implications of
this.
I am not sure how Forms authentication would work - the sample using
passwords on the site you recommended had passwords stored in the config
file
- we are using SQL Server authentication to authenticate users. Or maybe
I
am getting confused as to what you meant. I think I understand the
concept
of setting the authorisation cookie etc, but I didn't know if this could
be
used to store the password that they entered on the login page, or if it
could, would it be safe?
Thanks
Siobhan

"Wilco Bauwer" wrote:

> Sorry, I meant Sparky Arbuckle.
>
> Siohban: you can place those textboxes in a usercontrol, such as
> Login.ascx. You can place this login control on a login page. If you
> lookup how forms authentication works, it should be fairly
> straightforward to figure out how to get information based on a user's
> ID. Such a user ID can be persisted across pages (using sessions).
>
>


Nov 19 '05 #14

P: n/a
Ok Thanks
Siobhan

"Nikander & Margriet Bruggeman" wrote:
In that case you won't be able to benefit from connection pooling. The logon
credentials have to match exactly for pooling. In general web apps don't lend
themselves too well for client/server apps kind of things. If you're worrying
about scalability you'll have to seriously reconsider if every user must have
it's own unique sql server login. Of course you could create a unique login
for every user but use a general account for all sql connections...

If you're worrying about storing passwords safely... Storing the passwords
in a Session object as it is is not exactly very safe. If you want you could
use the DPAPI library or the MS Encryption application block to encrypt
passwords before you store them in a Session object. Hth.

Kind regards,
Nikander & Margriet Bruggeman
"Siobhan" wrote:
Hi
The application we are writing is a database application in which each user
must have a unique SQL Server login to allow for auditing of certain
information. Most of the functions of the system are database driven so
database access is unavoidable. At this stage it won't be a large system but
I am just trying to get a handle of this for future developments.
Can I just ask about connection pooling, if each user has a different
username and password does this make the connection string different and
therefore each login won't use the pool?
Thanks
Siobhan

"Joe Fallon" wrote:
Siobhan,
In a large system the DB tends to be the bottleneck so you want to access it
only when truly needed.
You can always add more web servers to handle the load. Scaling the DB is
quite a bit trickier.

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


"Siobhan" <Si*****@discussions.microsoft.com> wrote in message
news:80**********************************@microsof t.com...
> Hi
> Yes this is what we have done before but we are passing the data using a
> session variable and I had just been worried about the implications of
> this.
> I am not sure how Forms authentication would work - the sample using
> passwords on the site you recommended had passwords stored in the config
> file
> - we are using SQL Server authentication to authenticate users. Or maybe
> I
> am getting confused as to what you meant. I think I understand the
> concept
> of setting the authorisation cookie etc, but I didn't know if this could
> be
> used to store the password that they entered on the login page, or if it
> could, would it be safe?
> Thanks
> Siobhan
>
> "Wilco Bauwer" wrote:
>
>> Sorry, I meant Sparky Arbuckle.
>>
>> Siohban: you can place those textboxes in a usercontrol, such as
>> Login.ascx. You can place this login control on a login page. If you
>> lookup how forms authentication works, it should be fairly
>> straightforward to figure out how to get information based on a user's
>> ID. Such a user ID can be persisted across pages (using sessions).
>>
>>

Nov 19 '05 #15

P: n/a
Ok - thanks for your help
S

"Sparky Arbuckle" wrote:
Sessions is a good start. Reading into Sessions Object you can even
preset the user's login and password into a Session Object that carries
with them across their web experience.

Nov 19 '05 #16

P: n/a
Yes. Differing UID/PWD settings for the connection string kill the benefits
of connection pooling.
Doing so is a huge mistake.

You do not need to do that at all.

The unique UID and PWD that each user signs in to the app with is all you
need.
When you update the DB you use the UID stored in your User BO.
(You should also have a date field in each table that is updated using the
default getdate() function.)
Now you know who changed the record and when.

And by having a single connection string for DB access, you gain the
benefits of scalability.
--
Joe Fallon

"Siobhan" <Si*****@discussions.microsoft.com> wrote in message
news:2F**********************************@microsof t.com...
Hi
The application we are writing is a database application in which each
user
must have a unique SQL Server login to allow for auditing of certain
information. Most of the functions of the system are database driven so
database access is unavoidable. At this stage it won't be a large system
but
I am just trying to get a handle of this for future developments.
Can I just ask about connection pooling, if each user has a different
username and password does this make the connection string different and
therefore each login won't use the pool?
Thanks
Siobhan

"Joe Fallon" wrote:
Siobhan,
In a large system the DB tends to be the bottleneck so you want to access
it
only when truly needed.
You can always add more web servers to handle the load. Scaling the DB is
quite a bit trickier.

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


"Siobhan" <Si*****@discussions.microsoft.com> wrote in message
news:80**********************************@microsof t.com...
> Hi
> Yes this is what we have done before but we are passing the data using
> a
> session variable and I had just been worried about the implications of
> this.
> I am not sure how Forms authentication would work - the sample using
> passwords on the site you recommended had passwords stored in the
> config
> file
> - we are using SQL Server authentication to authenticate users. Or
> maybe
> I
> am getting confused as to what you meant. I think I understand the
> concept
> of setting the authorisation cookie etc, but I didn't know if this
> could
> be
> used to store the password that they entered on the login page, or if
> it
> could, would it be safe?
> Thanks
> Siobhan
>
> "Wilco Bauwer" wrote:
>
>> Sorry, I meant Sparky Arbuckle.
>>
>> Siohban: you can place those textboxes in a usercontrol, such as
>> Login.ascx. You can place this login control on a login page. If you
>> lookup how forms authentication works, it should be fairly
>> straightforward to figure out how to get information based on a user's
>> ID. Such a user ID can be persisted across pages (using sessions).
>>
>>


Nov 19 '05 #17

P: n/a
If I wanted to use a single user name and password to connect where would I
put this so that it would be secure - I wouldn't want it hard-coded as this
would require a rebuild if it needed changed?
Thanks
Siobhan

"Joe Fallon" wrote:
Siobhan,
In a large system the DB tends to be the bottleneck so you want to access it
only when truly needed.
You can always add more web servers to handle the load. Scaling the DB is
quite a bit trickier.

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


"Siobhan" <Si*****@discussions.microsoft.com> wrote in message
news:80**********************************@microsof t.com...
Hi
Yes this is what we have done before but we are passing the data using a
session variable and I had just been worried about the implications of
this.
I am not sure how Forms authentication would work - the sample using
passwords on the site you recommended had passwords stored in the config
file
- we are using SQL Server authentication to authenticate users. Or maybe
I
am getting confused as to what you meant. I think I understand the
concept
of setting the authorisation cookie etc, but I didn't know if this could
be
used to store the password that they entered on the login page, or if it
could, would it be safe?
Thanks
Siobhan

"Wilco Bauwer" wrote:
Sorry, I meant Sparky Arbuckle.

Siohban: you can place those textboxes in a usercontrol, such as
Login.ascx. You can place this login control on a login page. If you
lookup how forms authentication works, it should be fairly
straightforward to figure out how to get information based on a user's
ID. Such a user ID can be persisted across pages (using sessions).


Nov 19 '05 #18

P: n/a
In ASP.Net 1.1 most people add the connection string to the web.config file.
This file can be changed at any time so it is not really "hardcoded" as you
do not need to re-compile.

A minor concern is that an Admin can read the web.config and learn your
string. (Pretty tough for anyone else to do it.)

In version 2.0 of ASP.Net there are encrypted sctions so that no one can
read the value.

You can implement your own security in 1.1. if you need to.
--
Joe Fallon

"Siobhan" <Si*****@discussions.microsoft.com> wrote in message
news:B0**********************************@microsof t.com...
If I wanted to use a single user name and password to connect where would
I
put this so that it would be secure - I wouldn't want it hard-coded as
this
would require a rebuild if it needed changed?
Thanks
Siobhan

"Joe Fallon" wrote:
Siobhan,
In a large system the DB tends to be the bottleneck so you want to access
it
only when truly needed.
You can always add more web servers to handle the load. Scaling the DB is
quite a bit trickier.

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


"Siobhan" <Si*****@discussions.microsoft.com> wrote in message
news:80**********************************@microsof t.com...
> Hi
> Yes this is what we have done before but we are passing the data using
> a
> session variable and I had just been worried about the implications of
> this.
> I am not sure how Forms authentication would work - the sample using
> passwords on the site you recommended had passwords stored in the
> config
> file
> - we are using SQL Server authentication to authenticate users. Or
> maybe
> I
> am getting confused as to what you meant. I think I understand the
> concept
> of setting the authorisation cookie etc, but I didn't know if this
> could
> be
> used to store the password that they entered on the login page, or if
> it
> could, would it be safe?
> Thanks
> Siobhan
>
> "Wilco Bauwer" wrote:
>
>> Sorry, I meant Sparky Arbuckle.
>>
>> Siohban: you can place those textboxes in a usercontrol, such as
>> Login.ascx. You can place this login control on a login page. If you
>> lookup how forms authentication works, it should be fairly
>> straightforward to figure out how to get information based on a user's
>> ID. Such a user ID can be persisted across pages (using sessions).
>>
>>


Nov 19 '05 #19

P: n/a
Ok - Thanks Joe

"Joe Fallon" wrote:
In ASP.Net 1.1 most people add the connection string to the web.config file.
This file can be changed at any time so it is not really "hardcoded" as you
do not need to re-compile.

A minor concern is that an Admin can read the web.config and learn your
string. (Pretty tough for anyone else to do it.)

In version 2.0 of ASP.Net there are encrypted sctions so that no one can
read the value.

You can implement your own security in 1.1. if you need to.
--
Joe Fallon

"Siobhan" <Si*****@discussions.microsoft.com> wrote in message
news:B0**********************************@microsof t.com...
If I wanted to use a single user name and password to connect where would
I
put this so that it would be secure - I wouldn't want it hard-coded as
this
would require a rebuild if it needed changed?
Thanks
Siobhan

"Joe Fallon" wrote:
Siobhan,
In a large system the DB tends to be the bottleneck so you want to access
it
only when truly needed.
You can always add more web servers to handle the load. Scaling the DB is
quite a bit trickier.

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


"Siobhan" <Si*****@discussions.microsoft.com> wrote in message
news:80**********************************@microsof t.com...
> Hi
> Yes this is what we have done before but we are passing the data using
> a
> session variable and I had just been worried about the implications of
> this.
> I am not sure how Forms authentication would work - the sample using
> passwords on the site you recommended had passwords stored in the
> config
> file
> - we are using SQL Server authentication to authenticate users. Or
> maybe
> I
> am getting confused as to what you meant. I think I understand the
> concept
> of setting the authorisation cookie etc, but I didn't know if this
> could
> be
> used to store the password that they entered on the login page, or if
> it
> could, would it be safe?
> Thanks
> Siobhan
>
> "Wilco Bauwer" wrote:
>
>> Sorry, I meant Sparky Arbuckle.
>>
>> Siohban: you can place those textboxes in a usercontrol, such as
>> Login.ascx. You can place this login control on a login page. If you
>> lookup how forms authentication works, it should be fairly
>> straightforward to figure out how to get information based on a user's
>> ID. Such a user ID can be persisted across pages (using sessions).
>>
>>


Nov 19 '05 #20

This discussion thread is closed

Replies have been disabled for this discussion.