Hi Jeff!

I'm going to jump in here to keep this moving.

Therefore, why would the same method AuthenticateUser from the same SF Security DLL assembly work for the WinForm and not for the Webform?

As Trent has said, this indicates that something isn't wired correctly.  The reason for debugging is to figure out what isn't wired correctly.

To setup the SF for debugging, you just need to open the SF source code project in VS and then build it in debug mode.  This adds the debugging tokens and puts the built dll into the appropriate place for this to work.  Be sure that the source your using matches the version your using.

Once this is done, I set a break point on the call to the AuthenticateUser and then step into SF code. When you get to the line Trent indicated you can investigate what's going on with the data retrieved. You can also check SecurityKeys, DataSource connections strings etc.

Greg/Trent,

I will be glad to debug the code to find out what is going on.  I am sorry but I really don't know how to setup the Security DLL to be able to put it into debug mode so I can set a break point within it when I am calling it from my project.  I have never done this before.  I need step by step instructions.

Thanks,

Jeff

Hi Jeff.

1 - Download and install the source code from the SF website under My Account / Downloads if you haven't done so yet.

2 - Open the SF solution: "C:\Program Files (x86)\MicroFour\StrataFrame Source Code\MicroFour StrataFrame.sln"

3 - Set the Solution Configurations combobox to Debug:



If the combobox is not visible on the Build Toolbar, check the menu Tools / Options and check the "Show advanced build configurations":



You can also go to the menu Build / Configuration Manager and set the Configuration column:



4 - After this, Build the solution, which should place the DLLs onto the Common Files and the Assembly folders. Get out of Visual Studio. Please, check if the GAC was updated. You can even delete the SF DLLs from it and copy the ones from the Common Files folder ("C:\Program Files (x86)\Common Files\MicroFour\StrataFrame")



5 - Now, open your solution and set the break point as Trent and Greg have adviced you and you should be able to step into the SF code.

Hope it helps.

Hi Ivan,

Thanks for the info.  I already knew all of that, I must have been doing something wrong.  It is now enabling me to break into the code.  BTW, you probably knew this but I needed to build the Security Solution. 

After I am done troubleshooting, should I rebuild it in the Release mode?

Thanks,

Jeff

About rebuilding it into Release mode during development, I think that is your choice, either way.

Glad you got it going.

Hi Trent,

Here are the results once I have stepped through Login Class:

Class Login

AuthenticateUser(...)

'-- Retrieve the user for the given username

loUsersBO.FillByUserName(Username)

.Count = 1 (Correct)

us_PK = 45 (Correct)

.DataSourceKey = "" (Correct)

If Not loUsersBO.IsDataValid() Then

Public Function IsDataValid() As Boolean

Me._UserName = "jeff" (Correct)

Return Me._Hash = CreateMD5HashHex(Me._UserName)

Returning - Me._Hash = "" (?????)

End Function

Return LoginResult.Failure

End If

The IsDataValid returns (_Hash = "") which is where the problem is. Therefore, IsDataValid() condition is True and returns LoginResult.Failure.

Assuming I'm reading your post correctly, the IsDataValid method returns false, thus Me._Hash != Me._UserName. (Me._UserName == "Jeff" and Me._Hash == "", right).

My first guess is that you haven't setup the security key and vector to match what is going on in the windows app, though this is a pretty shaky guess at this point.  It seems that the only possible way this could be doing what you're seeing is if the data field from the row isn't decrypted correctly, and thus the has would not match.

The code that loads the BO sets the hash using what is already stored in the Data field.  Thus, if there is a problem returning the correct original string from that hash, which uses the security vector and salt, then you'll end up with problems. I'm doing a bit more investigation, but this might solve the problem, so I thought I'd post it sooner rather than later.

That is correct.

I think what everyone is forgetting here is this exact same table and user record that the AuthenticateUser function is calling works just fine from a Windows Form.  However, when I make the same call with the exact same table and user record from a WEB Form is when the IsDataValid is returning False (

Jeff,

I've not forgotten about it.  I am going to setup a test as I know that this is a configuration issue.  If you could supply a sample that would be even better, so that we are working on the same set of settings and data.  But I will see if I can tell where you are going wrong.  I have never seen a situation this hard to setup, so there is definitely something in the mix.

Not forgetting, just trying to figure out why.

Check that the SetSecurityKeyAndVectorForUserAuthentication() is using the same key in both the windows and web app.

If that doesn't work, you may need to setup a sample app that reproduces the issue. The solution would include a winform app and a web project both using the same security db (that you'd include and that would obviously be a test db, not a real one).