[RESOLVED] winforms to web

Hi all,

I have been browsing and reading reading reading to find the simplest way to develop a webforms authentication page that connects to an existing sql 2008 server and authenticates against it.

I am trying to keep this as simple as possible, but every example i've come across is a gazillion lines of code in order to accomplish "is this username in the database, and if so does the password match" - if the answer to that is yes, let 'em in.

I'm seeing the login controls of asp.net where it uses the entire security model - etc etc.....all i want to do is have a page with username and password fields and a login button on it, check it against an already existing table that has only two fields in it - username and password.......

IIS is 7.5 and is on one server and SQL is 2008R2 on another.....

is there a quick and dirty solution to this?



***EDIT*** By the way, I'm a winforms guy up to this point and this will be step 1 in putting this app together for the web. It currently exists as a winform app

Have a look at Dana's post here:

http://www.vbforums.com/showthread.php?t=538737

Depending on where you are headed with this application, it might make sense to look into using the Membership/Roles/Profile Provider that ships with .Net. The only problem is that in order to use this, you will have to create a Custom Provider, that is probably what you have seen on the internet.

Gary

I did that once in a project back in .NET 1.1. I don't know if you can even do it this way anymore, but here's the code:

Code:

---

Private Sub btnLogin_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnLogin.Click
        Dim intSecurityLevel As System.Int32    ' Security Level

        ' If Validator Controls are Validated
        If IsValid Then
            ' Try to logon against the Database
            If Login(txtUserName.Text, txtPassword.Text, intSecurityLevel) Then

                ' Set Security and Logon Session variables for
                ' controlling how the other pages work
                Session("Security") = intSecurityLevel
                Session("Login") = txtUserName.Text

                ' Authenticate the web site
                System.Web.Security.FormsAuthentication.RedirectFromLoginPage(txtUserName.Text, _
                                                        ckbCookie.Checked)
            End If

        End If
    End Sub

    Private Function Login(ByRef strUsername As String, _
                            ByVal strPassword As String, _
                            ByRef intSecurityLevel As System.Int32) _
                            As Boolean
        Dim boolResult = False          ' Function result
        'Dim strDBPassword As String   
        Dim strSQL As String            ' SQL Statement
        Dim drReader As SqlClient.SqlDataReader ' SQL Data Reader

        ' SQL SELECT Statement to read Logon info for Username
        strSQL = "SELECT * FROM Security WHERE Username = '" & _
            Replace(strUsername, "'", "''") & "'"

        ' Try to catch any exceptions
        Try

            ' If the SQL Connection is closed, open it
            If SqlConn.State = ConnectionState.Closed Then
                SqlConn.Open()
            End If

            ' Set SQL Command SQL Statement
            SqlCom.CommandText = strSQL

            ' Execute the SQl Data Reader
            drReader = SqlCom.ExecuteReader

            ' If a match row is found
            If drReader.HasRows Then

                ' Read the record
                drReader.Read()

                ' If the password provided matches the password in
                ' the database, set function result to true
                If drReader.Item("Password") = strPassword Then
                    intSecurityLevel = drReader.Item("SecurityLevel")
                    strUsername = drReader.Item("Username")
                    boolResult = True
                End If
            End If

            ' Close the data reader
            drReader.Close()

            ' Catch any exceptions
        Catch ex As Exception

            ' Finally, if it excepted or not
        Finally

            ' If the SQL Connection is open, close it
            If SqlConn.State = ConnectionState.Open Then
                SqlConn.Close()
            End If
        End Try

        Return boolResult  ' Return result
    End Function

---

And in the web.config I put:

Code:

---

    <authentication mode="Forms">
   
                <forms name=".SECOTMCookie" loginUrl="/SECOTaskManager/TMLogin.aspx" protection="All" timeout="80" path="/"/>                       
   
    </authentication>


    <!--  AUTHORIZATION
          This section sets the authorization policies of the application. You can allow or deny access
          to application resources by user or role. Wildcards: "*" mean everyone, "?" means anonymous
          (unauthenticated) users.
    -->
    <authorization>
        <!-- <allow users="*" /> --> <!-- Allow all users -->
        <deny users="?"/>

            <!--  <allow    users="[comma separated list of users]"
                            roles="[comma separated list of roles]"/>
                  <deny      users="[comma separated list of users]"
                            roles="[comma separated list of roles]"/>
            -->
    </authorization>

---

Maybe that will help...

thanks to you both.....and thanks for the code - will give it a shot.....

from what i'm seeing though, if i want to conform to any type of standard in order to comply with future development then this puppy should be done with the full asp database/security provider/login functions that i've already looked at

i'm also toying with Silverlight 4 as well....should be interesting and will report back with results

thx again guys.

Hey,

I would agree with that.

Are you tied into your existing database? Starting from scratch with a new database is very easy, the only complexity is when you have an existing database.

Gary

yeah, database is existing.......

is there any way to add all the necessary items to manage it from within that database as it sits now? because really, i'm only after user name and password - what's going on right now is it authenticates through a standard winforms login screen......

The provider model is great but I tend to avoid it because it adds a tone of tables and stored Procs to the database unless I do a custom implementation, there is also alot more code than if I do it myself (even if it's hidden I know it was generated). Implementing the providers gives you drag and drop use of the login controls but they are so simple anyway I have never been enticed by that feature. To each their own.... someday I'm going to make a website using all the VS built in features - maybe it'll have to be my own.

To simply use forms authentication to test username/password it's just a login page and specifing which folders are secure in the web.config.

ex.

Code:

---


'connect to database

'query table and return username if valid
example query --- "Select username From table where user = @user and pass = @pass"
'create command, add parameters bla bla
dim user as string = myCommand.executeScalar()

if string.isNullorEmpty(user) then
  'invalid give message
else
  'valid login
  FormsAuthentication.RedirectFromLoginPage(user, false)
end if

---

Because asp.net does all the checking of authentication the restricted resources you specify in the web.config are protected, so that's it - in its simplest form.

brin,

Agreed, the Provider does add a lot of tables and stored procedures to your database, but it also adds a lots of functionality, which, if you were to implement yourself would take a fair amount of work. I personally like using the Providers, I use them against a MySql Database, and everything just works. As for the built in controls not being to your taste, you can take full control of those, changing their templates as required.

trevorjeaton, if you need to use an existing database, with the built in Membership Provider Model and associated controls, you have no choice but to create your own custom membership provider. This basically means that you have to tell the provider model where it can find all the information it needs, and inform it when authentication has happened correctly.

How many users are we talking about here, and how much other information is there in your exist database? Basically, what I am asking is, can you start again?

Gary

hi guys - we're talkin 53 users and then scaling up to roughly 100.

the existing database consists of 20 or so tables, one of which is the 'login' table that has prompted this whole adventure.

if i were to start over using the providers on the database side of things, is it just a question of letting the wizard generate all those tables and then maybe bcp'ing the data in to the newly formed database? ie, recreate the fields and definitions with the same names so the winforms internal can continue functioning normally....

in the end, roughly 25 internal users will continue using the winforms app internally while the other (eventual) 75 external users will migrate to the asp.net deployment.

Hey,

If you are going to be using the same database for both the Windows Form Application and your Web Application, I would be tempted to suggest the you put a Web Service between the database and your applications, that way there is a common interface for both applications, thus reducing the potential surface area of the database being exposed.

Essentially, yes, that is what would need to happen. Are you using the current username for userid as a foreign key in any of your other tables? If so, this would also need to change.

Gary

Quote:

---

Originally Posted by trevorjeaton

yeah, database is existing.......

is there any way to add all the necessary items to manage it from within that database as it sits now? because really, i'm only after user name and password - what's going on right now is it authenticates through a standard winforms login screen......

---

Yes you can do it with the command line tool aspnet_regsql.exe, which will open an app that prompts you on which database you want to add the necessary tables and store procs to. This link gep posted last month helped me ALOT.

http://www.4guysfromrolla.com/articles/120705-1.aspx

Hey,

Yes, this will do as Sean says, what you would still need to manually pull the information over from your existing tables, this won't happen for you automatically.

Gary

Quote:

---

Originally Posted by gep13

Hey,

Yes, this will do as Sean says, what you would still need to manually pull the information over from your existing tables, this won't happen for you automatically.

Gary

---

And probably do clear passwords in the custom provider?

To start with, that would have to be the case, yes.

Otherwise, you would need to reset everyone's password so that the hash/encryption algorithm can kick in and store it in the database.

Gary

okay, so as i put this together moving forward, to answer the questions above, yes clear text would be the password transmission type of choice at the start and then i could enforce a password change rule later on, so it sounds like we'd be okay there.

for the remainder, and correct me if i'm wrong or have steps out of place here - but as a roadmap, i would:

1. add the tables to the existing database as per the asp model using the command line tool

2. migrate my existing data and if necessary, username and password info into that database as well

3. at that point, my internal winforms app (with some code tweaking) should still be able to authenticate (by pointing it to the newly added tables and user info that i've updated manually) and function as usual

4. i now have the table structure in place for the web side of things added to the existing 20 tables or so in current use, so i should then....

5. get a service between the two to minimize the exposure of the database (will likely have more questions on this later)

6. begin asp development while winforms app keeps running as it normally should internally

oh and also, the current username is only a string field and any foreign keys are being handled by a user id field which is also a primary key - its numeric at this point

Hey,

This is what I was getting at though, that UserId field will be recreated when you add users into your new tables, so you would have to go through and change these userid's in your other tables.

The slight issue that you are going to have is that the ASP.Net Membership Provider is just that, an ASP.Net Membership Provider, so it is not directly available to a Windows Form application, so in your list above, you would likely need to do 5 before 3.

Gary

ah okay, i didn't know that - i thought i would be able to redirect the authentication that is currently in use to the the newly added asp.net tables.....

so in moving forward, what would be a better approach to place a common service between the two app types - forms and web? there's WCF correct? and ria if we walk down the silverlight road.....

keep in mind this is a winforms guy that is now branching into asp.net so i may need baby steps here - i can pick up the logic very quickly of course, but in working through the logic of this thread i'm trying to create a "user manual" of sorts that hopefully others can follow, as i'm sure there's a ton of winforms apps that alot of dev's would love to "webinize" too :-)

Quote:

---

Originally Posted by gep13

Hey,

This is what I was getting at though, that UserId field will be recreated when you add users into your new tables, so you would have to go through and change these userid's in your other tables.

The slight issue that you are going to have is that the ASP.Net Membership Provider is just that, an ASP.Net Membership Provider, so it is not directly available to a Windows Form application, so in your list above, you would likely need to do 5 before 3.

Gary

---

If he is just using a username and a password, and he is using clear passwords, what's to prevent him from authenticating his winform just by querying against that table? If he needs it to reference his old stuff, he can extend the table and add the userID to the other table.

Hey,

There is nothing to stop him doing that, it all comes down to a question of architecture. If you are exposing a shared database openly to everyone, then you run the risk of something happening that you are not expecting, some deleting something, changing something they shouldn't etc. Granted, you can restrict the permissions on the database to prevent this from happening, but at the end of the day, your full database is open.

Putting a webservice between your application (both web and windows) means that you reduce the potential surface area for attack, only exposing the methods that you want/need to.

This approach also has the added benefit of having the same code for accessing the database in both applications, it is all done through the web service.

Gary

Quote:

---

Originally Posted by trevorjeaton

ah okay, i didn't know that - i thought i would be able to redirect the authentication that is currently in use to the the newly added asp.net tables.....

so in moving forward, what would be a better approach to place a common service between the two app types - forms and web? there's WCF correct? and ria if we walk down the silverlight road.....

keep in mind this is a winforms guy that is now branching into asp.net so i may need baby steps here - i can pick up the logic very quickly of course, but in working through the logic of this thread i'm trying to create a "user manual" of sorts that hopefully others can follow, as i'm sure there's a ton of winforms apps that alot of dev's would love to "webinize" too :-)

---

If you are looking to take baby steps, then I would stick with pure ASP.Net just now, make sure you have that under your belt, and you know the basics. Then you can start with WCF and Silverlight. They are both great technologies, but there is a bit of a learning curve, and both built on the principles that you are away to learn in ASP.Net.

Gary

Quote:

---

Originally Posted by gep13

Hey,

There is nothing to stop him doing that, it all comes down to a question of architecture. If you are exposing a shared database openly to everyone, then you run the risk of something happening that you are not expecting, some deleting something, changing something they shouldn't etc. Granted, you can restrict the permissions on the database to prevent this from happening, but at the end of the day, your full database is open.

Putting a webservice between your application (both web and windows) means that you reduce the potential surface area for attack, only exposing the methods that you want/need to.

This approach also has the added benefit of having the same code for accessing the database in both applications, it is all done through the web service.

Gary

---

I guess I was kind of assuming this was an internal application he is writing, where security threats wasn't a huge issue.

okay so having said that - your assistance in "lets begin" would be appreciated....

if i leave the database open with a larger surface area for things to get out of hand (deletions/unauthorized edits/ etc), that's okay at the moment because the app itself really restricts database access and displays info more than it allows changes - i have roles already in the winforms app that range from guest thru admin - of which at the momemt I am the only admin for those exact reasons) but i would of course love to be able to lock it down later after proof of concept has been achieved.

the idea of common code between both apps is HIGHLY appealing by the way, but can that also be added later? again, after proof of concept?

if i can register a domain name (i have), create a new asp.net project in visual studio 2010, slap username and password fields on it and a 'login' button and when you click that button, it checks my existing login table for those credentials and if successful redirects to a page that states "congratulations, you logged in", and that's it..... that would be success for me because now everybody can still use the winforms app and i can begin the learning curve in which i can hit you guys up with a million questions :-) while still allowing the winforms app to log in and function normally

then publish that simple little page to the domain, set up IIS to allow authentication to the database on the second server and voila, baby step number 1 has been taken and is the first one in to the larger world of asp or silverlight, or any of the many other technologies.....while everybody continues to work in the winforms app none the wiser that their application is now slowly being turned to the web while i start learning......

or am i being too ambitious at this point?

Quote:

---

Originally Posted by trevorjeaton

okay so having said that - your assistance in "lets begin" would be appreciated....

---

I will try my best :)

Quote:

---

Originally Posted by trevorjeaton

the idea of common code between both apps is HIGHLY appealing by the way, but can that also be added later? again, after proof of concept?

---

Certainly, everything can be refactored, it is just how much "re-work" you want to have to do. If you plan up front, then you can limit this amount of "throw-away" code. You also mention Roles, that is something that is covered in the ASP.Net Roles Provider, which you might also want to take a look at. Again, if you are happy to, you can transfer these Roles in the Roles Provider, and let ASP.Net take care of it. If you want to see an example of this in action, take a look at the Restricted Menu link in my signature.

Quote:

---

Originally Posted by trevorjeaton

if i can register a domain name (i have), create a new asp.net project in visual studio 2010, slap username and password fields on it and a 'login' button and when you click that button, it checks my existing login table for those credentials and if successful redirects to a page that states "congratulations, you logged in", and that's it..... that would be success for me because now everybody can still use the winforms app and i can begin the learning curve in which i can hit you guys up with a million questions :-) while still allowing the winforms app to log in and function normally

then publish that simple little page to the domain, set up IIS to allow authentication to the database on the second server and voila, baby step number 1 has been taken and is the first one in to the larger world of asp or silverlight, or any of the many other technologies.....while everybody continues to work in the winforms app none the wiser that their application is now slowly being turned to the web while i start learning......

or am i being too ambitious at this point?

---

Nope, I don't think you are being too ambitious, I think this approach makes sense for starting out. I was simply offering those others suggestions as food for thought. Sounds like you have given them some thought, and are going to work towards them in an incremental fashion, which is perfectly valid.

The one thing that I would mention is that you mention you are using Visual Studio 2010 (that's a good thing, there are so many improvements in it) and I am assuming that you are targeting the .Net 4.0 Framework, have you checked to make sure that your web host supports .Net 4.0?

For your first baby step, I would recommend you use Dana's example from post #2, that should get you started.

for the web host, we are the host with a 100 meg fiber line comin in, so we're in house on this one - i haven't looked in to .net 4 on IIS, but the hosting server is a 2008 R2 box.

Ah, ok, that's fine, this means you will have all the control that you need.

The .Net 4.0 Framework is available for download if you don't already have it, and it can easily be installed side by side with all the other frameworks.

Gary

the existing winforms app is also vs 2010 by the way and targeting .net 4 as well. Are there any special considerations to be looked at when deploying .net 4 on the IIS server?

That's ok.

Nope, the only real consideration is to make sure that the web application under IIS is set to use .Net 4.0 for the application that it is hosting.

Within IIS manager, if you right click on the web site, and select properties, go to the ASP.Net tab, and make sure that 4.0 is selected.

These instructions are for IIS 6, it is a slightly different route if you are using IIS 7.

That should be about it.

Gary

okay so at this point, i'm going to mark this thread as resolved, because reaaly, what this discussion has given me, and hopefully the others that are following it is the methodology, logic, and choices that must be made and followed if you have a winforms app that you need to migrate over to the web while retaining a common database between the two.

There will many more posted in the near future by me, but i consider this thread the launching point for the first "baby step"

Thanks a million to all who contributed, and i most certainly will be popping up in future threads probably even starting today :-)

thanks again everyone

Sounds like a plan to me.

Will keep an eye out for your future posts :)

Gary