Securing Content

Next you'll want to secure your content.

There are a couple of ways to handle authentication in an application:

• Global Authentication
• Individual Page Authentication

Global Authentication

You should use global authentication handled in OnProcessInit() if your application's user always need to be logged in for all or most operations. If all or most requests require the user to be logged in, then global authentication is the way to go.

The auto-installer automatically creates a block of code in OnProcessInit() like this that supports both of these options:

*** Share the cookie with the UserSecurityManager cookie
THIS.InitSession(Server.oConfig.oUserSecurityManagerProcess.cCookieName,3600,.T.)

*** Global Authentication Mode
LOCAL lnLoginMode
lnLoginMode = 0  && 0-no auto authentication, 2-force login
IF lnLoginMode = 2
		*** Authenticate each request and force a login
		*** to all requests EXCEPT the ones in the list
		lcScriptName = LOWER(JUSTFNAME(Request.GetPhysicalPath()))
		
		*** Update this list with any endpoints that
		*** DON'T AUTHENTICATE
		llIgnoreLoginRequest =  INLIST(lcScriptName,;
		  "default")
		 IF !THIS.Authenticate("any","",llIgnoreLoginRequest)
		   IF !llIgnoreLoginRequest
		     RETURN .F.
		   ENDIF
		ENDIF
ENDIF

Set the mode to 2 if you want all requests - except those you explicitly exclude like the default page above - are accessible only if the user is authenticated.

Per Request Authentication

If your application is mostly open but has a few requests that require explicit logins (like a user profile or adding data perhaps), you can use per request authentication using code like this in a process method:

FUNCTION SecuredContent()

IF !this.Authenticate("ANY")
   RETURN   && forces a login
ENDIF   


Response.ExpandScript()
ENDFUNC
*   SecuredContent

The call to Authenticate("ANY") causes Web Connection to check whether the user is authenticated and by default if she is not, bringing up the authentication dialog to force the user to log in. The login automatically captures the current URL and if login ends up successful, the user is sent back to the original page she was trying to access.

Individual Authentication requests work well in scenarios where most requests are open access, and a few requests require authentication.

Authentication Properties

You can check various Authentication properties on the Process class to see whether the user is logged in and who the user is.

• Process.lIsAuthenticated
• Process.cAuthenticatedUser (username - typically email address)
• Process.cAuthenticatedName (Display Name)
• Process.oUser (user profile record)

To check if a user is logged in you can use Process.lIsUserAuthenticated and you can check for a specific user with .cAuthenticatedUser or .cAuthenticatedName.

Understanding the Process.oUser Property

If you need more granular control than just "is this user logged in" you can also access the Process.oUser (or this.oUser in a process method) property. This method provides you full access to the wwUserSecurity user record which includes the username, fullname, admin status, active status entered date and so on - all of it is accessible.

The typical check sequence for programmatic validation is:

• Check Process.lIsAuthenticated
• Check Process.oUser.UserName or Process.oUser.Level for determining rights

In script code you can do things like:

<% if Process.oUser.Level > 8 %>
   <a href="AdminReport.st">Admin Report</a>
<% endif %>

You can also check for Admin accounts that have the Admin flag set:

<% if Process.oUser.Admin %>
   <a href="Administration.wc">Web Connection Administration</a>
<% endif %>