Persisting user login credentials across pages

[Siobhan]

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

[Sparky Arbuckle]

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>

[Sparky Arbuckle]

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

[Siobhan]

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

[Sparky Arbuckle]

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?

[Siobhan]

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?

[Wilco Bauwer]

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.

[Siobhan]

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.

[Wilco Bauwer]

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).

[Sparky Arbuckle]

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.

[Siobhan]

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).

[Joe Fallon]

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).

[Siobhan]

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).

[Nikander & Margriet Bruggeman]

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).
>
>

[Siobhan]

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).
>>
>>

[Siobhan]

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.

[Joe Fallon]

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).
>>
>>

[Siobhan]

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).

[Joe Fallon]

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).
>>
>>

[Siobhan]

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).
>>
>>