Re: Persisting user login credentials across pages

From: Joe Fallon (jfallon1_at_nospamtwcny.rr.com)
Date: 02/22/05 

Date: Mon, 21 Feb 2005 20:56:25 -0500

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" <Siobhan@discussions.microsoft.com> wrote in message 
news:2F682777-6586-4F36-82E3-0B4B223AC6C3@microsoft.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.RedirectFromLoginPage(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.aspx?area=CSLA%20.NET
>> -- 
>> Joe Fallon
>>
>>
>>
>>
>> "Siobhan" <Siobhan@discussions.microsoft.com> wrote in message
>> news:80905982-FCCE-4917-878A-7F0BFFC88135@microsoft.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).
>> >>
>> >>
>>
>>
>>

Relevant Pages

  • Re: Persisting user login credentials across pages
    ... In ASP.Net 1.1 most people add the connection string to the web.config file. ... "Siobhan" wrote in message ... >> Sample code requires you to have a login method on your Principal class ... >>> I am not sure how Forms authentication would work - the sample using ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Can no longer connect as sa
    ... > Is there a reason you need to connect using SQL authentication? ... >> Login failed for user 'sa'. ... >> I can't figure out what is slightly different in the connection string. ...
    (microsoft.public.sqlserver.setup)
  • Re: EXEC master..xp_cmdshell Prevention
    ... > I found that my web application did use a connection string in a file ... > stored procedures for every SQL statement would be impractical. ... I have created a new login account ...
    (microsoft.public.sqlserver.security)
  • Windows Authentication connectionstring Login failed for user Gue
    ... authentication to access SQL Server using the sa login. ... sa login, I want to convert the app to use Windows Authentication. ... Then I changed the connection string to: ...
    (microsoft.public.data.ado)
  • Re: Can no longer connect as sa
    ... Is there a reason you need to connect using SQL authentication? ... > Login failed for user 'sa'. ... > I can't figure out what is slightly different in the connection string. ...
    (microsoft.public.sqlserver.setup)
Loading