Topic
  • 8 replies
  • Latest Post - ‏2013-01-16T21:26:44Z by afarris7
afarris7
afarris7
61 Posts

Pinned topic Login Page - Replace specified location with action results.

‏2013-01-11T16:31:26Z |
Hello,

I am currently using "Post-Action Behavior - Replace specified location with action results" in one of my models. This is similar to the Calculator_ReplaceLocation example in http://www-10.lotus.com/ldd/pfwiki.nsf/dx/ibm-using-ajax-techniques.

This is running as a portlet on a protected page. After some time the session expires. If the tag is refreshed from the html event action it refreshes the area with the login page content since it never makes it to the actual action. The login page actually replaces the location on the page.

I need to be able to detect this and redirect the browser to the proper login page. Has anyone run into this?

Thanks
Updated on 2013-01-16T21:26:44Z at 2013-01-16T21:26:44Z by afarris7
  • Dinger
    Dinger
    117 Posts

    Re: Login Page - Replace specified location with action results.

    ‏2013-01-11T17:53:26Z  
    Couple of ideas here. Ideally you would be able to use "Post-Action Behavior - Smart Refresh" or "Post-Action Behavior - Refresh specified page location after running action", since these options automatically handle the case of a session timeout. If either of these options works in your case, then you could use one of them to solve the problem. Without knowing more details, I couldn't say whether one of these options would work for you or not, but I thought I'd mention them.

    Otherwise, you would need to detect a session timeout condition during the execution of your action (on the server), or detect that the login page had been returned (on the client). It's probably easier to detect the session timeout on the server, in which case you could return a page fragment from your action that will reload the whole page. I assume you'd want the entire page to reload if the session timed out, so that only the login page is displayed. I haven't actually tried this approach, so if you have trouble getting it to work, let me know and I'll try to build a quick sample.

    The content of this post is my own and does not necessarily represent the positions, strategies, or opinions of IBM.
  • afarris7
    afarris7
    61 Posts

    Re: Login Page - Replace specified location with action results.

    ‏2013-01-11T19:17:59Z  
    • Dinger
    • ‏2013-01-11T17:53:26Z
    Couple of ideas here. Ideally you would be able to use "Post-Action Behavior - Smart Refresh" or "Post-Action Behavior - Refresh specified page location after running action", since these options automatically handle the case of a session timeout. If either of these options works in your case, then you could use one of them to solve the problem. Without knowing more details, I couldn't say whether one of these options would work for you or not, but I thought I'd mention them.

    Otherwise, you would need to detect a session timeout condition during the execution of your action (on the server), or detect that the login page had been returned (on the client). It's probably easier to detect the session timeout on the server, in which case you could return a page fragment from your action that will reload the whole page. I assume you'd want the entire page to reload if the session timed out, so that only the login page is displayed. I haven't actually tried this approach, so if you have trouble getting it to work, let me know and I'll try to build a quick sample.

    The content of this post is my own and does not necessarily represent the positions, strategies, or opinions of IBM.
    I am using "Replace specified location with action results" option because this page is large. So I don't want to pull down the whole page each time to update a small section.

    If I am not mistaken the request never makes it to the action on the server? It redirects in the portal environment to the login page before making it to the action. So I don't think I can do anything on the server side.
  • Dinger
    Dinger
    117 Posts

    Re: Login Page - Replace specified location with action results.

    ‏2013-01-11T20:21:20Z  
    • afarris7
    • ‏2013-01-11T19:17:59Z
    I am using "Replace specified location with action results" option because this page is large. So I don't want to pull down the whole page each time to update a small section.

    If I am not mistaken the request never makes it to the action on the server? It redirects in the portal environment to the login page before making it to the action. So I don't think I can do anything on the server side.
    Yeah, I think you're right about that. In the small sample I was playing with, I didn't actually wait for a session timeout, I just treated the second request for the page as a session timeout and returned a different page.

    I'll look into how you might determine (client-side) if the returned page is the login page (or some other page you weren't expecting), and then reload the entire page in that case.

    The content of this post is my own and does not necessarily represent the positions, strategies, or opinions of IBM.
  • afarris7
    afarris7
    61 Posts

    Re: Login Page - Replace specified location with action results.

    ‏2013-01-11T22:36:17Z  
    • Dinger
    • ‏2013-01-11T20:21:20Z
    Yeah, I think you're right about that. In the small sample I was playing with, I didn't actually wait for a session timeout, I just treated the second request for the page as a session timeout and returned a different page.

    I'll look into how you might determine (client-side) if the returned page is the login page (or some other page you weren't expecting), and then reload the entire page in that case.

    The content of this post is my own and does not necessarily represent the positions, strategies, or opinions of IBM.
    Not as elegant as I want but this seems to work. Thoughts?
  • Dinger
    Dinger
    117 Posts

    Re: Login Page - Replace specified location with action results.

    ‏2013-01-16T07:05:14Z  
    • afarris7
    • ‏2013-01-11T22:36:17Z
    Not as elegant as I want but this seems to work. Thoughts?
    I think the problem with this approach is that it makes two requests each time. One to see if there was a session timeout, and one to either replace the content or display the login page. Ideally, you'd only want to make a second request in the case of reloading the page on a session timeout. I came up with two ways to accomplish this with a single request in the non-timeout case.

    The first attached model (HandleSessionTimeoutOnPostEvent) uses a Client Event Handler builder call to handle the AjaxPostLoad event. WEF fires this event on the client after the request is made and the content has been replaced. The Javascript I use for handling this event looks at the content of the element whose content was replaced, determines whether it is a login page, and reloads the page if it is. The disadvantage to this approach is that the content gets replaced before the handler can reload the page, so the login page may be briefly visible in the replaced area of the page before the page gets reloaded. The advantage of using this method for detecting a session timeout is that it's a supported technique, so it should continue to work in future versions of WEF.

    The second attached model (HandleSessionTimeoutOnUpload) uses a Client JavaScript builder call to define a new update function for the PPR handler that replaces the content. In order to make sure the Javascript can find the correct button, I also use a Unique Client-Side ID builder call to give the button a unique ID. The Javascript finds the name of the PPR handler in the onclick handler of the button, and then defines a new update function for that handler. This new update function looks at the content to determine if it's a login page, and reloads the page if it is. Otherwise, it calls the original update function to replace the content. The advantage to this approach is that a session timeout will cause the page to be reloaded before the content is replaced. The disadvantage is that this approach is a bit non-standard, so there's a chance that it may not work in future versions of WEF.

    I added several comments to the Javascript in both models to help explain what's going on. Feel free to ask if anything I did isn't obvious.

    The content of this post is my own and does not necessarily represent the positions, strategies, or opinions of IBM.
  • afarris7
    afarris7
    61 Posts

    Re: Login Page - Replace specified location with action results.

    ‏2013-01-16T15:02:17Z  
    • Dinger
    • ‏2013-01-16T07:05:14Z
    I think the problem with this approach is that it makes two requests each time. One to see if there was a session timeout, and one to either replace the content or display the login page. Ideally, you'd only want to make a second request in the case of reloading the page on a session timeout. I came up with two ways to accomplish this with a single request in the non-timeout case.

    The first attached model (HandleSessionTimeoutOnPostEvent) uses a Client Event Handler builder call to handle the AjaxPostLoad event. WEF fires this event on the client after the request is made and the content has been replaced. The Javascript I use for handling this event looks at the content of the element whose content was replaced, determines whether it is a login page, and reloads the page if it is. The disadvantage to this approach is that the content gets replaced before the handler can reload the page, so the login page may be briefly visible in the replaced area of the page before the page gets reloaded. The advantage of using this method for detecting a session timeout is that it's a supported technique, so it should continue to work in future versions of WEF.

    The second attached model (HandleSessionTimeoutOnUpload) uses a Client JavaScript builder call to define a new update function for the PPR handler that replaces the content. In order to make sure the Javascript can find the correct button, I also use a Unique Client-Side ID builder call to give the button a unique ID. The Javascript finds the name of the PPR handler in the onclick handler of the button, and then defines a new update function for that handler. This new update function looks at the content to determine if it's a login page, and reloads the page if it is. Otherwise, it calls the original update function to replace the content. The advantage to this approach is that a session timeout will cause the page to be reloaded before the content is replaced. The disadvantage is that this approach is a bit non-standard, so there's a chance that it may not work in future versions of WEF.

    I added several comments to the Javascript in both models to help explain what's going on. Feel free to ask if anything I did isn't obvious.

    The content of this post is my own and does not necessarily represent the positions, strategies, or opinions of IBM.
    Thanks for these examples, this is gold. I didn't know this.ids gets passed to the event script.

    I like the second model

    I guess my last concern would be if the session was not timed out, there could be alot of a html the javascript would have to search through everytime. Should I worry about this?

    Is there anyway to look at the response headers from the ajax call in function(data, idlist) instead of searching through all the html? I know specific headers that are unique to the login page.

    Something like in http://www.ibm.com/developerworks/library/wa-ajaxintro3/
    Listing 10. Print all the response headers from a HEAD request
    
    function updatePage() 
    { 
    
    if (request.readyState == 4) 
    { alert(request.getAllResponseHeaders()); 
    } 
    }
    


    Thanks again
  • Dinger
    Dinger
    117 Posts

    Re: Login Page - Replace specified location with action results.

    ‏2013-01-16T21:20:44Z  
    • afarris7
    • ‏2013-01-16T15:02:17Z
    Thanks for these examples, this is gold. I didn't know this.ids gets passed to the event script.

    I like the second model

    I guess my last concern would be if the session was not timed out, there could be alot of a html the javascript would have to search through everytime. Should I worry about this?

    Is there anyway to look at the response headers from the ajax call in function(data, idlist) instead of searching through all the html? I know specific headers that are unique to the login page.

    Something like in http://www.ibm.com/developerworks/library/wa-ajaxintro3/
    Listing 10. Print all the response headers from a HEAD request
    <pre class="jive-pre"> function updatePage() { if (request.readyState == 4) { alert(request.getAllResponseHeaders()); } } </pre>

    Thanks again
    The logic I used for the session timeout check was just copied from the model you posted earlier. I didn't really think about the performance implications of doing it this way. But honestly, I wouldn't worry about it unless you know it is causing a problem. It seems like it would produce minimal performance overhead compared to the other things going on.

    If you determine that this logic is causing unacceptable performance overhead, there are a couple things I can think of to try that might make it perform better. One is your idea about looking at the response headers. Unfortunately, I don't think those are available in the update() function or the event handler, at least I couldn't figure out how to get at them. And if you could get them from somewhere, it might require additional non-standard logic in your application. :-( Another idea would be to look at the size of the response data. This would take some trial and error, but if you could determine a predictable size range of your login page, then you would only have to do the indexOf() calls for responses in that size range. Or, if you know what the login page looks like, you might be able to tailor your code to look at a certain part of the response instead of the whole response. That might perform better, or it might not. Realize also that these last two ideas introduce the risk of not testing a response that really is a login page.

    An alternate approach would be to put something into a valid response that you can search for. For example, maybe the returned markup could have a hidden span with a unique ID near the end of the response, and you could look for it using a fromIndex parameter to indexOf(). Just an idea that I haven't tried.

    Bottom line, I'd make sure you have a problem before spending the time to solve it.

    The content of this post is my own and does not necessarily represent the positions, strategies, or opinions of IBM.
  • afarris7
    afarris7
    61 Posts

    Re: Login Page - Replace specified location with action results.

    ‏2013-01-16T21:26:44Z  
    • Dinger
    • ‏2013-01-16T21:20:44Z
    The logic I used for the session timeout check was just copied from the model you posted earlier. I didn't really think about the performance implications of doing it this way. But honestly, I wouldn't worry about it unless you know it is causing a problem. It seems like it would produce minimal performance overhead compared to the other things going on.

    If you determine that this logic is causing unacceptable performance overhead, there are a couple things I can think of to try that might make it perform better. One is your idea about looking at the response headers. Unfortunately, I don't think those are available in the update() function or the event handler, at least I couldn't figure out how to get at them. And if you could get them from somewhere, it might require additional non-standard logic in your application. :-( Another idea would be to look at the size of the response data. This would take some trial and error, but if you could determine a predictable size range of your login page, then you would only have to do the indexOf() calls for responses in that size range. Or, if you know what the login page looks like, you might be able to tailor your code to look at a certain part of the response instead of the whole response. That might perform better, or it might not. Realize also that these last two ideas introduce the risk of not testing a response that really is a login page.

    An alternate approach would be to put something into a valid response that you can search for. For example, maybe the returned markup could have a hidden span with a unique ID near the end of the response, and you could look for it using a fromIndex parameter to indexOf(). Just an idea that I haven't tried.

    Bottom line, I'd make sure you have a problem before spending the time to solve it.

    The content of this post is my own and does not necessarily represent the positions, strategies, or opinions of IBM.
    Looking at the size would be a great idea. I appreciate all your help.