OpenEdge Mobile login timeout and intercept JSDO request

Posted by spserna2 on 01-Apr-2015 08:48

Hi all,

my app is currently using the form authentication provided by the default session login of the Mobile App Builder.

So, the session will be timed out after the app idle for some time and all subsequent JSDO request will be unauthorized.

What is the best way to handle the login session between the app and the server?

1. Intercept the JSDO request to investigate the XHR for 404 respond , then redirect user back to the login screen

2. Keep the session alive by server side configuration

Is it possible to intercept the JSDO request respond at global level rather than handle it at the onerror event in every request?

Mobile - Forum

All Replies

Posted by Shelley Chase on 01-Apr-2015 11:14

Hi,

Great question! It is always a good idea to handle the unauthorized error on the client especially with web and mobile where an app might continue running in the background and the user has no intention of coming back anytime soon.

The Session is designed to handle the error at a global level with the offline event. Any error returned from a JSDO request is processed by the Session and you can check the error code in that event.

Another thing to consider is any data in JSDO memory that might be related to the user since you do not want that data to remain if another user logs in on the "re"-login screen.

We are looking into the specific behavior of the Session object in this specific case and will provide more specific information when it is available. I believe this would be a good topic to cover in session management best practices.

Thanks

-Shelley

Posted by spserna2 on 02-Apr-2015 04:20

Hi schase,

thanks for pointing me to the Session offline event,

I think I have found the details document to that,

documentation.progress.com/.../index.html

I believe to access my session object, I will have to look at Offline event at the first App page

I also have to figure which error reason code is referring to the session timeout...

Consider my app will only be used by the phone owner, the data could remain in the JSDO memory

What do you think about asking user to re-login every time the session timeout ?

This is unlike most mobile app where it usually has a one time two-factor authentication. However, we are bound to the limitation of OpenEdge Mobile service which is Tomcat Java servlet container.

I wonder saving credential and manually refresh the session in background would be a feasible idea, then again we will have all the security concern.

I do hope there is a better way to prolong the session duration or seamlessly refresh the session status.

Posted by whenshaw on 03-Apr-2015 15:25

If an acceptable solution is to stop the timeout from happening, you could try pinging the server on some interval, so the server receives a request even if the user doesn't do anything. You can have the Session service ping for you by setting its pingInterval property  > 0 (the number specifies milliseconds). You can do this by adding a "Run JavaScript" handler on Success of SessionService_Login. Here's an example that sets the ping interval to 5 seconds:

If you want to catch the error from a timeout, you are correct that you can use the Offline event available in the Mobile App Builder. Specifically, you need to use the Offline event of the SessionService_Session object (in an Express app generated for you by PDSOE, it is named DefaultSession -- see the example below). This event should fire if the JSDO makes a request that fails due to a session timeout (it might fire for other reasons too, of course). I think it would be somewhat complicated to automatically log back, but we can give you some specific suggestions if you want to try that approach (and you are correct to be concerned about security -- you would need to store the credentials securely, of course).

Regards,

Wayne

Posted by whenshaw on 03-Apr-2015 15:45

Here are graphics that should have accompanied my last post.
 
pingInterval:
 
 
 
And Offlien event:
 
 
 
 
 
 
 
 
[collapse]
From: spserna2 [mailto:bounce-spserna2@community.progress.com]
Sent: Thursday, April 02, 2015 5:22 AM
To: TU.Mobile@community.progress.com
Subject: RE: [Technical Users - Mobile] OpenEdge Mobile login timeout and intercept JSDO request
 
Reply by spserna2

Hi schase,

thanks for pointing me to the Session offline event,

I think I have found the details document to that,

documentation.progress.com/.../index.html

I believe to access my session object, I will have to look at Offline event at the first App page

I also have to figure which error reason code is referring to the session timeout...

Consider my app will only be used by the phone owner, the data could remain in the JSDO memory

What do you think about asking user to re-login every time the session timeout ?

This is unlike most mobile app where it usually has a one time two-factor authentication. However, we are bound by the limitation of OpenEdge Mobile service which is Tomcat Java servlet container.

I wonder saving credential and manually refresh the session in background would be a feasible idea, then again we will have all the security concern.

I do hope there is a better way to prolong the session duration or seamlessly refresh the session status.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by spserna2 on 27-Apr-2015 04:22

Hi whenshaw, thanks for looking up this issue and spending effort on capturing the screenshot for me.

I was planning to intercept the failing request at default session 'offline' event, and navigate back to the login page when i have a request with status code 401 (timeout issue)

To proof that this is working, I decided to log the session and request object on offline event.

To reproduce the timeout issue, I log in with the test emulator and left it idle for > 3 hours, I presume I will able to receive a log about the connection lost issue. After the long wait and none of the log appeared, I navigated to a page to initiate a READ request and I received 401 error. I'm looked at the log again and none of session information been logged. 

I manually disconnected my Laptop internet connection and then the offline log appeared. 

I may be wrong here but I have a look at the progress.jsdo.3.2.js code, it seen that it does not handle the offline event due to Form Authentication SessionId lost.

Posted by whenshaw on 27-Apr-2015 15:09

You are correct. My apologies for giving you the wrong information about the offline being able to catch session timeout. As you can see from the comment in the Session code, it tries to be conservative when it decides whether the server is offline.
 
Here is one other thing to try: Instead of using the pingInterval property to tell the DefaultSession to call ping automatically, you can call the ping() method yourself. If you do this, you can specify a callback function (which you cannot do with the automatic pinging). The session code will pass this callback the XMLHttpRequest object that was used to do the ping, so you can use that to try to figure out whether the 401 means that the server session has expired. This approach might work if you can assume that, if there was a successful login but now you get a 401, that means the session has expired,
 
I talked with our Security Architect about getting more precise information from an OpenEdge Web application when there is a session timeout or a similar event. That is something we would like to do in the future (no promises though, I’m afraid), but at the moment we don’t have the support for it.
 
Below is a rough example of how to do what I described above. It worked in a test app, using an OE Mobile Web application that uses Form authentication and that has its session-timeout set to 3 minutes.
 
In my app, I added the following code as a handler for the DefaultSessionLogin Success event, instead of setting the pingInterval there. I did not subscribe to the Online and Offline events, though you may want to do that for other reasons. Note that in my test app, the name of the DefaultSessionLogout service is DefaultSessionLogoutCustomer -- yours may be different:
 
function pingComplete( pingResultArgs ) {
    if ( pingResultArgs.pingResult ) {
        if ( pingResultArgs.xhr.status === 401 &&
             DefaultSessionLogin.service.pdsession.loginResult === progress.data.Session.SUCCESS) {
            alert("Session has timed out.");  // probably !!!!
            DefaultSessionLogoutCustomer.execute( {} );  // log out to reinitialize DefaultLoginSession
        }
    }
}
 
function intervalFunction() {
    DefaultSessionLogin.service.pdsession.ping( { aynsc: true,
                                                  onCompleteFn: pingComplete } );
}
 
setInterval( intervalFunction, 1000 * 60 * 4);  // Set the 2nd argument to some useful number
 
 
 
 
 
 
 
[collapse]
From: spserna2 [mailto:bounce-spserna2@community.progress.com]
Sent: Monday, April 27, 2015 5:23 AM
To: TU.Mobile@community.progress.com
Subject: RE: [Technical Users - Mobile] OpenEdge Mobile login timeout and intercept JSDO request
 
Reply by spserna2

Hi whenshaw, thanks for looking up this issue and spending effort on capturing the screenshot for me.

I was planning to intercept the failing request at default session 'offline' event, and navigate back to the login page when i have a request with status code 401 (timeout issue)

To proof that this is working, I decided to log the session and request object on offline event.

To reproduce the timeout issue, I log in with the test emulator and left it idle for > 3 hours, I presume I will able to receiving a log about the connection lost issue. After the long wait and none of the log appeared, I navigate to a page to initiate a READ request and I receive 401 error. I'm looked at the log again and none of session information been logged.

Then I manually disconnected my Laptop internet connection and then the offline log appeared. I may be wrong here but I have a look at the progress.jsdo.3.2.js code, it seen that it does not handle the offline event due to Form Authentication SessionId lost.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

This thread is closed