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 (

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.

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.

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

Glad you got it going.

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

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.

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!

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.

Hi Trent,

As I mentioned in my previous posts, I have a test WinForm in a Windows project as part of the same solution which works just fine using the AuthenticateUser method.  That was the first thing I tested before contacting the forum to verify my code was correct.  Therefore, why would the same method AuthenticateUser from the same SF Security DLL assembly work for the WinForm and not for the Webform?

If you still want me to debug the Strataframe security module then exactly how do I compile the module into debug mode, point to the DLL and step into the code.  I haven't done this before.

Jeff 

No, otherwise the password would not be secure.  It is embedded and encrypted.  This is why I wanted you to debug.  This way you can see what is returned.  By not debugging, what could be a 5 minute problem could drag into days going back and forth on the forum.  In the Login class in StrataFrame, the AuthenticateUser method will give you the answer:

On line 462 of Login.vb in the MicroFour StrataFrame Security assembly, you will see what is going on .  There you can see what is retrieved and step until you see the password verified.  I am going blind here.  The only other option is to send me a sample that reproduces the steps....though I don't think that this is feasible since it is environment and getting this reproduced and to me may take even longer.

One other thought, in the WinForm app, manually call the AuthenticateUser method on a test form and see if you get the same results.