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?
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:
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.
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?
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).
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.)