I downloaded the security zip.. extract it put it in the projects folder.. you docs say to run it.. so i try to compile it and run and I cant even open the project because of the attached error.. This server was build 6..7 days ago... everything on it is brand new install the only wconnect that's ever been on this server is wc712..

++ jim --

Make sure all your paths are set to include the Web Connection libraries. It sounds like your Web Connection environment is not set up properly and you're missing the paths back to find the Web Connection libraries.

Either:

• Start in the folder with the shortcut so config.fpw can be found
• Explicitly change to the deploy folder and run DO SetPaths

If you just open FoxPro and cd into the folder the Web connection libraries are not going to be found so make sure that SET("PATH") includes the right folder where your Web Connection installation lives.

Also just to make sure you do a CLEAR ALL/CLOSE ALL before running DO UserSecurityManagerMain to ensure you are not running with the files from the Console (should be an issue, but just to be sure).

I've done this about 10 times today so I know it works.

+++ Rick ---

Make sure all your paths are set to include the Web Connection libraries. It sounds like your Web Connection environment is not set up properly and you're missing the paths back to find the Web Connection libraries.

Either:

• Start in the folder with the shortcut so config.fpw can be found
• Explicitly change to the deploy folder and run DO SetPaths

If you just open FoxPro and cd into the folder the Web connection libraries are not going to be found so make sure that SET("PATH") includes the right folders for the Install classes folder and the WC install root where your Web Connection installation lives.

Also just to make sure you do a CLEAR ALL/CLOSE ALL before running DO UserSecurityManagerMain to ensure you are not running with the files from the Console (should be an issue, but just to be sure).

I've done this about 10 times today so I know it works.

+++ Rick ---

this is my shortcut properties

target: "C:\Program Files (x86)\Microsoft Visual FoxPro 9\vfp9.exe" -c"c:\webconnectionprojects\usersecuritymanager\deploy\config.fpw"

startin: c:\wconnect\

after it opens vfp I cd to C:\webconnectionprojects\UserSecurityManager

run setpaths.prg which contain

SET PATH TO ("C:\wconnect") ADDITIVE

SET PATH TO ("C:\wconnect\classes") ADDITIVE

SET PATH TO ("C:\wconnect\tools") ADDITIVE

I ran the autoroutine.. went over to my target project to recompile it.. there was also a new error message this time "Unable to find unknown HASHMD5"

I don't know, you need to do some troubleshooting on your end. I don't know why your libraries aren't loadin, but it's an environment problem.

• CD and make sure you ARE in fact in the \WebConnectionProject\UserSecurityManager\Deploy folder
• Print SET("PATH") and see if the WWC paths are in there
• DO WCONNECT in your project folder
• ? SET("PROCEDURE") to see if there are a ton of Web Connection PRGs

If any of those are not there, then you need to see why that is. If classes are not showing - delete all FXP files in your project folder and in the Web Connection startup and classes folders.

I've been running into a problem with an empty wconnect.fxp file (in the WWWC root folder). No idea where that's coming from but that's causing the libraries to not load. Shows up every once in a while after project creation. It's possible that's what you're seeing. To check do FULLPATH("wconnect.fxp") and if it's not in the \wconnect\classes\ folder delete it. Heck even if it is delete the FXP and let it recompile on the next restart.

+++ Rick ---

Hi Jim I'm running into the same problems you were. Did you ever get it to work?

Hi Rick

I'm encountering the same issues as Jim Monte. Is there a solution?

User Security was written for Web Connection 7.x but it works fine on 8.0. Nothing has really changed there that affects the behavior. The sample uses older DLLs and lacks WebConnectionWebServer launch mode, but other than that it should work the same as a new app. These things shouldn't matter anyway once you add the features to an existing project.

Not sure why you'd need a reference to wwResponsefile.prg unless your main Web Connection setup includes the the Legacy setting.

If you have this:

#DEFINE INCLUDE_LEGACY_RESPONSEMETHODS  .T.

in your wconnect.h file in your Web Connection install folder, or wconnect_override.h in your project folder, then you have to include the classes\Old_Files folder in your path so those libraries can be found.

User Security shouldn't need them - I just fired up my sample app install and it runs with no issues and I have do not included the legacy features or added the OldFiles path.

The library probably could use an update to get the DLLs up to date, but the core process class and support templates etc. all should work either way.

+++ Rick ---

Hi Rick, Thanks for the reply. I've been trying to get this to work but have been having probs. Getting the usersecuritymanager prj to open requires me to locate the files its seeking (wwresponefile.prg etc) then I can run run UserSecurityManager_ServerConfig.prg and build the project but get this error from IIS

HTTP Error 500.19 - Internal Server Error The requested page cannot be accessed because the related configuration data for the page is invalid.

Detailed Error Information: Module IIS Web Core Notification BeginRequest Handler Not yet determined Error Code 0x8007000d Config Error
Config File \?\c:\webconnectionprojects\usersecuritymanager\web\web.config Requested URL http://localhost:80/UserSecurityManager Physical Path c:\webconnectionprojects\usersecuritymanager\web Logon Method Not yet determined Logon User Not yet determined

I tried running UserSecurityManager_AddToProject.prg anyway and it does run and sets up usersecurity in the prj I add it to but it doesn't entirely work. Shows up as sign-in and goes to the sign in page, creates a user then returns to the default page when It displays sign-in and not signed in as.

I tried doing the process manually also with out success. Got any ideas how I can start debugging and try to figure this out.

Thanks, Jim

That sounds like an IIS Error? You need to run the config as an Administrator (it should prompt you to let you know). I won't work without that.

If you're doing local development - especially on Windows Home - I would recommend using IIS Express or the .NET Web server. IIS works, but you have to make sure it's installed with your Windows setup and if you're running on Windows Home there may be pieces missing (like Windows Authentication - which I think this error relates to). Refer to the IIS Set up instructions in the Web Connection docs.

It's been a while since I've looked at the user manager, so off the top of my head I don't remember the process for setting up. If I recall there's a sample process class you create that you can then merge into a project of your own. Is that what you're doing?

+++ Rick ---

Hi Rick, I'm both using the automated script and manual steps to add sec to my projects. I do run the server setup as administrator. I checked out the web.config file that IIS is complaining about and although its different than that of the existing prj I have it's not that different. Does it even matter if the usersecurity prj is properly setup in iis? The addproject code seems to work. I just don't want to spend too much time solving a problem I don't need to solve.

If I use IIS Express will I need to recode the project before deploying to an actual server with IIS? And what do I do about existing prjs that were setup for IIS?

Thanks Jim

I downloaded iis express and rebuilt the usersec project - it still wants the old files but built and displayed in the browser. However it has the same problems I encountered when adding to other prjs. The signin is there but will never show anything else other than signin.

What are you doing exactly? How are you setting up and running? There are a few ways you can do this...

+++ Rick ---

Hi Rick, I'm trying to get the Web Connection User Security Manager to work. I installed iis express and that solved the issue with IIS. It runs, shows in the browser but it never authenicates so the signin widget never shows anything but signin this code here (!Process.lIsAuthenticated) Response.Write([]+ CRLF +; []+ CRLF +; [ ]+ CRLF +; [ Sign in]+ CRLF +; []) everything else works as far as the login. I can add new data to the dbf, using test@test.com works but the widget never shows that.

not sure what you mean - How are you setting up and running? running win10 webconnection 8.2

What I mean is how did you set this up? Are you trying to run the sample project?

+++ Rick ---

Ok finally had a chance to dig into this a little deeper. So, I was able to duplicate what you see - the authentication wasn't working. Essentially what was happening is that the cookie was not being set properly.

Long story short, some of the changes in the security setup in 8.x behave slightly different than in prior versions and that caused the cookie not to be set when the auth classes are subclassed as they are for the User Security manager.

So, the fix for this is in the main framework:

In wwProcess::Authenticate find and update the following code:

IF Request.IsChecked("WebLogin_chkRememberMe")					
	LOCAL ltDate
	ltDate = DATETIME() + this.nAuthenticationTimeoutSeconds
	
	*** Keep the cookie around
	THIS.oResponse.AddCookie(this.cSessionKey,Session.cSessionId,"/",ltDate,"",.T.,.F.)	
ELSE 
	*** THIS CODE WAS MISSING!
	THIS.oResponse.AddCookie(this.cSessionKey,Session.cSessionId,"/","","",.T.,.F.)						
ENDIF

In previous versions the cookie was set elsewhere and when overriding like the User Security manager does the cookie didn't get set. Using that fix makes the authentication work...

Oddly this should have broken in other scenarios too - not just with the User Security manager, but I know it works because I use the auth in various places including here on the message board. So a bit perplexed how and when this was broken... but it works with that additional line of code.

+++ Rick ---

Also just for clarification, here's the process I used to test this out:

• Create a new Web Connection Project (SecurityTest)
• Make sure it works!
• Run the usersecuritymanager_addtoproject.prg
• Select your project and process class

Note: If you're using the .NET Core Web Server, make sure to shut it down and restart it after running the install tool as the added script map won't be visible to the server otherwise. Just stop and launch() again.

• Add:

*********************************************************************
FUNCTION TestPage()
************************

IF !THIS.Authenticate("ANY")
	RETURN
ENDIF
 
THIS.StandardPage("Hello World from the SecureProcess process",;
                  "If you got here, everything is working fine.<p>" + ;
                  "Server Time: <b>" + TIME()+ "</b>")
                  
ENDFUNC

• Run Launch
• Access Testpage.sp (the first link in the sample)
• Login page should come up
• Login with test user
• If successful you should get through to the TestPage content
• You should also have the Login widget in the toolbar to signout and manage your profile
• If you want auto-login for all pages modify loginMode in OnProcessInit()

Hi Rick,

Do you have plans to push an update for this any time soon?

Yes eventually... for now you can get it from the FoxProExperimental.zip.

I see the DLLs are in the zip as well as wwPageResponse which is not directly referenced in the thread. Dumb question time; as the only code shown is a very straightforward added ELSE in wwProcess, and an update to AddCookie in wwPageResponse, is it necessary to deploy the DLLs?

I also ran into something odd related to cookies and session but I'm going to start a separate topic for that.

No...

The DLL updates (I think it's only wwDotnetBridge.dll) is just a small bug fix - it's not going to break anything but it's not required.

+++ Rick ---

Got it.

Ah. Console.exe is in it as well but dated 7/1/24.

Shouldn't be. These are the files (minus the Zip file):

User error. I unzip into the same folder when I grab an experimental zip and I should have cleaned it out beforehand.