First of all I read the help and it instructed me to add the following line to Global.asax file:

SecurityBasics.IsWebEnvironment = true;

Then using the code copied from the help files (see below) I try to authicate the user.  However, the login fails.  I know this code and username and password works, because I used the exact same code from a Windows form.  When looking at the user name returned by SecurityBasics.CurrentUser after the authentication fails, it is 'Administrator' even though I am trying to authenticate another user.  What is wrong or what do I have to do to get this same code to work from a Web form? 

//-- Establish locals

StringBuilder sb = new StringBuilder();

String userName = "";

MicroFour.StrataFrame.Security.Login.LoginResult loResult;

//-- Attempt to authenticate the user

loResult = MicroFour.StrataFrame.Security.Login.SetLoggedInUser(this.txtUsername.Text, this.txtPassword.Text, "");

//-- If the result if Success, AdminLoggedOn, or SecMaintUserLoggedOn, the

// SecurityBasics.CurrentUser object will be changed to the correct user

//-- Do something based upon the result

switch (loResult)

{

case MicroFour.StrataFrame.Security.Login.LoginResult.Success:

sb.AppendLine("Login successful.");

userName = MicroFour.StrataFrame.Security.SecurityBasics.CurrentUser.UserName;

sb.AppendLine(userName);

this.lblMessage.Text = sb.ToString();

return true;

case MicroFour.StrataFrame.Security.Login.LoginResult.Failure:

this.lblMessage.Text = "Login failed.";

return false;

case MicroFour.StrataFrame.Security.Login.LoginResult.UserDeactivated:

this.lblMessage.Text = "User Deactivated.";

return true;

default:

this.lblMessage.Text = "Unexpected Error: No login result returned.";

return false;

}

}

 

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 

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.

By the way, I did some more troubleshooting and found that the _Cipher.Decrypt(...) method in the SFSUsersBO constuctor is throwing an exception when I am debugging from within the Web Form project. So the Me.ParseString(...) method is never called which causes the Me._Hash variable to be empty. Again, the method works fine from the Windows Form project. Within the attached zip file is a screen shot of the exception. I hope all of this helps.

Not seeing the attachment Jeff....

I tried to attached a sample solution duplicating the problem along with the exception image (8 MB) and it tells me I have exceeded my available space.  Therefore, I am going to email it to Trent/Support.

Hi Greg,

After clearing the attachments in my profile as you suggested, I was finally able to upload the attachment. 

It has a simple solution that duplicates the Web User Authentication failure which includes the Windows Form project (works fine), the Web project, my BO class library and the SQLServer express 2005 database.  Also, I did some more troubleshooting and found an exception was being thrown by _Cipher.Decrypt(…) method in the SFSUsersBO constructor when debugging from the Web Solution.  I have included a screen shot of the exception info.  By the way, I am using VS2008.

I haven't got this to run yet (I have to run an errand), but I did look at the code and the exception.  You don't have a call to SetSecurityKeyAndVectorForUserAuthentication. Add this line in global.asax at the end of the start app method and see if it works.

SecurityBasics.SetSecurityKeyAndVectorForUserAuthentication( "MySecurityKey" );

Let me know. If there is still a problem, I'll get it running and see what else might be the issue.

You got to be kidding me!!!! After a week and half of shear fustration it comes down to one simple missing line of code in the Global.asax to fix the issue.   Obviously, you had mention this line of code a few posts back.  But being new to ASP.NET, I was working off of the Global.asax in your Web Sample and I that's what got me confused.  After all of this, I hope this will help others who are getting started with ASP.NET using Strataframe RBS.  Probably it would be a good idea in the future to include this information in the Global.asax file in your Web Sample to help ASP.NET newbies like me.

Thank you for all of your help and the awesome support!!!!!!

Jeff

I glad that fixed the issue.    I'll talk to Trent about including a RBS version of a web sample too.  Thanks for you persistence in getting this working Jeff!

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

Good point, Greg!