Login Component

[Louis Nickerson]

Upon successful login of a user, I want to open my user table and write the value of a field to a protected session variable.

This variable will then be used in filter expressions to make sure that this customer can only see accounts and data that are related to their account.

Looking at the V8 Login component, I don't see any events to tie this action to.

Can anyone shed a little light on how this is accomplished.

Thanks,

Louis

[Pat Bremkamp]

Re: Login Component

There may be other ways, but I go through a page which is only code. You could also put the code in the next regular page. The code for this page is:

 
<%a5
'==== Get logged in user id code
dim pUser as p
Dim tbl as p
a5ws_logged_in_user_values(pUser,request,session)
if eval_valid("pUser.ulink") = .t.
 vUI=alltrim(pUser.ulink)
 tbl=table.open("[PathAlias.ADB_Path]\People")
 tbl.order("Pe_Id","Pe_Id = "+quote(vUI))
 session.__protected__UserId = vUI
 session.__protected__UserName = alltrim(tbl.Pe_dear)
 tbl.close()
end if
response.redirect("Ev_AdminList.a5w")
%>

Pat

[Louis Nickerson]

Re: Login Component

Pat,

I will give this a try.

Thanks for the help!

Louis

[Louis Nickerson]

Re: Login Component

Pat,

This worked like a charm. After much searching AND reading of the help files, I came across this code with it's accompanying explaination.

For those who might benefit from this post in the future...here's what I needed to accomplish and how it was done.

Visitors to the website are presented with a home page which contains a navigation component. On the navigation component, I have a button for the user to login.

Originally, that button was linked to my login.a5w page which contains the login component I created in the Web Security section of A5. I found myself successfully logging in, but couldn't see where I could place code to go out to my user table and retrieve the customer's account number and ultimately write it to a protected session variable for use throughout the users visit to the site.

Thanks to Pat's suggestion of using a page which performs this function as an intermediate step between logging in and being delivered to the requested page, I created an a5w page and named it V8_Maint_Get_Account_Number.a5w. The code that this page runs follows...

<%A5 
dim pUser as p
Dim tbl as p
a5ws_logged_in_user_values(pUser,request,session)
if eval_valid("pUser.ulink") = .t.
 vUI=alltrim(pUser.ulink)
 tbl=table.open("d:\a5v8webroot\database\tbl_User_Names")
 tbl.order("User_Name","User_Name = "+quote(vUI))
 session.__protected__DM_Account_Num = alltrim(tbl.Account_number)
 tbl.close()
response.redirect("v8_User_Menu.a5w")
end if
%>

What the above code accomplishes is this...

It opens my tbl_user_names table and finds the record where the user_name field matches the User ID the visitor logged on with. Next it writes the customer's account number to a protected session variable called session.__protected__dm_account_num. Next, it closes the table and finally redirects the user to my Menu Page for authorized users.

Finally, I made sure that v8_User_Menu.a5w was set to Login Required in the Web Security settings and then I changed the navigation link for logging on to link to v8_User_Menu.a5w.

Now, when a user loggs in, their account number will presist in the form of a session variable for the duration of the session.

Louis

[Steve Wood]

Re: Login Component

I liked Pat's method also and have started using it. Its much cleaner to have a page in between login and your application where you can set variables, etc. The only place this will slightly break down is when you set the Web Security Login Redirect Option to Page Assigned by User Profile. The concept will still work, but you will have to create one page for each of the different pages assigned by User Profile, and set variables on each of those pages.

I really wish there was an AfterValidate section on the new login component so this could all be done at that position.

[Louis Nickerson]

Re: Login Component

Steve,

I agree completly. My initial instincts were to look for the events that would fire within the login component and place my code there.

As you know, no such events exist. I kept struggling with the concept of using an intermediate page with code for the same reason as you...As long as the only way someone would log on was through my login button then all is fine, but as soon as someone navigates to a url or clicks a link to a page that requires login, this approach is out the window unless like you said, you want to create an extra a5w page for each login required page you have.

I think I will post this as a feature request and see where we end up.

Thanks

Louis

[Steve Wood]

Re: Login Component

but as soon as someone navigates to a url or clicks a link to a page that requires login, this approach is out the window

Well, no that's not true. Under normal settings, a user that visits a restricted page without being logged in will be auto-directed to the login.a5w page (if that's your login page).

[Louis Nickerson]

Re: Login Component

Steve,

Yes, as you say, they will be automatically directed to the login page if they attempt to access a Login Required page without being logged in, but once they log in you still face the dilemma of how to populate session variables with information from their user account.

Are you saying that there is a redirect command that can be placed in the intermediate (go get user info into variables) page that will remember the page they had originally requested?

I know I did this in version 6, but that was a long time ago and I'm a little rusty on the Wab App side of things. My current project is definately bringing me back up to speed, but with all the new (and very cool) features in V8 the learning process never ends.

Louis

[Steve Wood]

Re: Login Component

Are you saying that there is a redirect command that can be placed in the intermediate (go get user info into variables) page that will remember the page they had originally requested?

On testing I see that this IS the default behavior of the new security setup; and I don't see how to override. This is a big problem. If someone not logged in tries to go to ...page10.a5w and are shot back to the login page; once they log in they will be redirected back to the page10.a5w page - BYPASSING your intermdiate page that you are expecting to set variables. I will shoot an email off to Alpha to ask about this.

[Louis Nickerson]

Re: Login Component

Steve,

As we have both said, an After_Validate event in the Login component would resolve this issue altogether.

Louis

[JerryBrightbill]

Re: Login Component

When a user is redirected to the login page from another page, a parameter is added to the url to tell the login code what page the user should go to after login. Looking at the url for the login, the parameter can be seen as "np" for "next page". On the page containing the login component, you can change that parameter or capture that parameter before the login component runs.

If "np" has no value, the system uses the page in the settings, or the user file if a user specified redirect is used. If it has a value, the user is redirected to that page. So, if you want to page to go somewhere other than the page in the settings, just set the value of "np" to the page you want. The variable �np� always has priority for redirects

To get the value of "np" passed to the login

if eval_valid("request.variables.np")
	org_np = request.variables.np
end if

Set the value to force the page redirect to "nextpage.a5w"

request.variables.np = "nextpage.a5w"

To force a redirect and send the original "next page" to your code page

dim org_np as c
if eval_valid("request.variables.np")
	org_np = request.variables.np
end if
request.variables.np = "nextpage.a5w?org_np="+ org_np

You could them use the value of "org_np" to redirect from "nextpage.a5w"

Unlike the suggested systems in A5V7 that rely on session variables, the A5V8 security does not rely on maintaining the user information in a session variable and therefore allows logins to span beyond sessions . Therefore, only populating the session variables once after login is a bit dangerous. A session can time out, removing the variables, but the user can remain logged in and access restricted pages. Populating the variables on any page that requires them is much more reliable. The function to return the current logged in user values is very fast and adds almost no overhead.

The function to get logged in user values also returns any user specified redirect page, so you could also choose to redirect to that instead of any other redirect sent to your "after login" page.

[Louis Nickerson]

Re: Login Component

Jerry,

Sorry for the delay in thanking you for your response...shortly after reading it this morning, I got a terminal case of "I've got to get away from this computer for a while" and took a much needed break.

I haven't tried your solution yet. It sounds like a viable workaround, but it sure would be nice if there was some "simple" method to reach the desired goal.

I have submitted an entry in the Feature Wishlist section of the forum. I don't know how difficult it would be to implement my suggestion or even if my suggestion in itself would produce a whole new set of problems, but if it is viable, it would save the masses from doing a whole lot of otherwise unnecessary work.

Your comments regarding a session timing out and deleting the variables causes me to once again have to re-think my approach.

I wonder...using the approach I am currently using...if every grid I display is filtered using a protected session variable, then even if the session timed out and and the variables were deleted, the user (being still logged in through the security framework) would be able to access restricted pages, but not be able to see anything other than a bunch of grids displaying no records...or would it be worse...

Would they receive an error page indicating that the session variable does not exist?

It's really this simple. The security features of the product give us the ability to link to an external table. I'm guessing that this feature was added so that we could log someone in, use the Ulink field to look up some data in an external table and then use that data throughout our application.

We're almost there, but not quite. Maybe I don't get it. Maybe I don't understand the "right" way to accomplish the desired task, or is it possible that this is a feature that could really use some enhancement?

Thanks again for your suggestions!

Kindest Regards,

Louis

[JerryBrightbill]

Re: Login Component

I wonder...using the approach I am currently using...if every grid I display is filtered using a protected session variable, then even if the session timed out and and the variables were deleted, the user (being still logged in through the security framework) would be able to access restricted pages, but not be able to see anything other than a bunch of grids displaying no records...or would it be worse...

Would they receive an error page indicating that the session variable does not exist?

It's really this simple. The security features of the product give us the ability to link to an external table. I'm guessing that this feature was added so that we could log someone in, use the Ulink field to look up some data in an external table and then use that data throughout our application.

We're almost there, but not quite. Maybe I don't get it. Maybe I don't understand the "right" way to accomplish the desired task, or is it possible that this is a feature that could really use some enhancement?

Your analysis in the first paragraph is accurate and one of the main limitations of session variables - they can time out. If the session variable is missing the impact will vary depending on how you are using it. If it is applying a filter, the filter won't evaluate and you may see all records.

You have to decide how to handle the problem of missing session variables based on your design. Normally, it is code such as

if eval_valid("session.yourvar") = .F.
    'do something
end if

That issue is outside of the security system as it doesn't rely on the persistence of session variables. If you check other posts, you will see that most people suggest always checking for the existance of session variables before they are needed. If you do that on every page that requires them, you can just repopulate them if they are missing.

[Louis Nickerson]

Re: Login Component

Jerry,

Once again, thank you for your input. Your suggestion is simple. In my case, I could redirect the user to a "Your Session Timed Out" page and require them to log on again.

I guess I'm just spoiled. I write X-Basic when I have to, but rely heavily on Action Scripting in the desktop environment. I was hoping that Alpha would see an enhancement to the security feature that would negate the necessity of placing code in every web page as an enhancement that would benefit the masses.

Regards,

Louis

[JerryBrightbill]

Re: Login Component

Actually, unless you need a value from the security system, you don't need any added code on a page. There are many situations where the built in security is more than sufficient since the security can control page access, field and update access in components, and menu options without any code being added. I think the limitation you are referring to is the fact that you can't filter directly on a security value. That isn't possible without populating a session variable or adding an override to a page since the filter value would likely come from some table outside of the security.

The biggest problem with web development is that there are so many different possible configurations and options. Most of us have become spoiled by the desktop side, but that has many years of design development. Until the recent availability of the component concept in Alpha Five, all web development was hand coded. The components help a lot, but there is still a need for some coding in special situations.

Adding events to the login really wouldn't help very much. You would still have to write xbasic, and an event would open many new areas for issues, since the login component doesn't work at all like a dialog. There really aren't any values available from the component that could be used for anything outside of the component.

We are working diligently to put together more information about the security, including more documentation and explanation of various options and ways to enhance the system using the available functions and features. There isn't a timetable on that, although there will be a session at the conference where all aspects of security will be discussed.