JSDO Refresh

Posted by spandau66 on 25-Apr-2016 10:07

Hi,

I've come across an issue with the JSDO and a user doing a Page Refresh.

I'm using Form Authentication.

If a User is logged into the 'app' and then decides to hit the Web page refresh, the page refreshes and then we see the message Resource xxxx not found. After debugging (rightly or wrongly) the JSDO Session is now empty! Therefore, my question is how do I resolve this issue?

Yes, I could use a cookie to store the current session and then re invoke that session (by the way that did not work). The other alternative is store the user Credentials and do a new login session!! But I believe this to highly dangerous and besides, I DO NOT like the idea of using Cookies or local storage (security implications).

What is the best approach on re-establishing the JSDO Session without having to do a secondary Log In? 

TIA

All Replies

Posted by whenshaw on 25-Apr-2016 13:34

Hello Martyn,

There is no complete, direct support in the JSDO library for making it easy to handle page refreshes, but adding that support is a priority for the team (though which specific features actually will make it into the next release is still being worked out).

One possibility for now, however: Instead of trying to store the current session and re-invoke it, have you tried this:

After a page refresh, create a new JSDOSession and then call its login() method, passing it no credentials. With Form authentication, the browser itself should still have the sessionid even after the refresh and pass it even on the login(). If the login succeeds, you will need to call addCatalog() again, because the catalog data was also destroyed by the page refresh. If the login() and addCatalog() succeed, there are two possibilities for the JSDO data. One is to simply fetch it again the same way you did when the app started. If you need to retain the data that the JSDO had before the page refresh, look into the JSDO's local storage API -- saveLocal(), readLocal(), addLocalRecords(), and deleteLocal(). These methods are in the documentation and there is a short example here:

  community.progress.com/.../53433

--Wayne

Posted by spandau66 on 26-Apr-2016 06:24

Hi Wayne,

Sadly that does not work :(

I start to see the issue with preflight!! (attached screen shot)

I'll attempt to run Fiddler2 and add more information later this afternoon. 

Martyn

Posted by spandau66 on 26-Apr-2016 09:41

Hi Wayne,

The issue is now resolved (it was a typo in my service adapter!!!).

Just one last question (two actually), when the login "login('','')" is performed after a page refresh, the username on the JSDO Session is now obviously empty. As we use the UserName value of the JSDO Session to display within our banner, would it be a sensible idea to use the savelocal and readlocal methods to repopulate the UserName on the login?

Second question: When invoking the logout(), I have to code the following:

           progress.data.ServicesManager._services = [];

           progress.data.ServicesManager._resources = [];

           progress.data.ServicesManager._data = [];

           progress.data.ServicesManager._sessions = [];

Is it worth changing the progress.all file to incorporate the above? If so, is placement important?

Many Thanks

Martyn

Posted by whenshaw on 27-Apr-2016 08:38

You would need to use the Window.sessionStorage API, since the saveLocal and readLocal methods are properties of the JSDO, not the JSDOSession (which is where the userName is).

             sessionStorage.setItem("namekey", jsdoSession,userName);

             sessionStorage.getItem("namekey");

Keep in mind that doing this exposes the user name more than it normally is, but at least using sessionStorage will get it cleaned up automatically for you when the browser tab is closed.

On the second question: If you know that you want to clear out the  catalog data in the ServicesManager every time you log out, it might be worth changing progress.all, but then of course you'd need to remember to put the change back in if you update progress.all.js. Another drawback is that if you plan to use the minified version of progress.all.js for deployment, you'd need to minify your modified progress.all.js and use that. As for placement, the onAfterLogout() function would be a good place.

An alternative to changing progress.all.js is to continue to include those statements in your code, in the handler for the promise returned from JSDOSession.logout(). (Unless that's what you're trying to avoid doing.)

(And, of course, if you modify the JSDO library and something goes wrong, remember to switch back to the official release version to eliminate your change as a possible cause of the problem before contacting technical support.)

This thread is closed