We have a financial application in which when a user opens a link in a new tab and closes the previous one his session is still active in the new tab. This can create issues of Cross Site Request Forgery which , to us, is a big issue. Talking to our developers about this in implementing something that uses onload or unload (as described here http://www.liferay.com/community/forums/-/message_boards/message/2948770) said that the way the application is build (Java+faces+jboss+tomact) will create issues as the use will be logged out each time he clicks on a menu. This is because the function is called whenever a user navigates from one page to another.
Is there a way around this issue without using the unload/onload Javascript function?
It is impossible to detect the user closing the page without using javascript.
However, it would be more user-friendly if you stored multiple CSRF tokens instead of just a single one (e.g. up to 10). When one is used, only this one is invalidated and when a new one is necessary, the oldest one is deleted.
This ensures people can work in multiple tabs while still having CSRF protection.
Related
My web site uses magic links for login, however, I have a problem on mobile (not sure about Android - haven't tried yet, but the problem exists at least on iOS): when a user receives the email say in the GMail app, the link opens in the embedded browser, meaning that cookies will not be passed to the "real" browser.
Is there a way to ensure the link in the email opens in the real system browser and therefore cookies are stored permanently?
(Essentially browser session isolation on iOS breaks a lot of things on the Internet, so surely there is a workaround?)
After some research: no, it is not possible to detect you are in an embedded browser, neither is it possible to enforce opening a link in the system one. Makes sense from security point of view.
However, I was asking the wrong question. The problem of a magic link login is solved differently: when starting a login process you can set a session cookie and create an associated DB record for it, marking it as blocked, i.e. not logged in.
At next step, when the magic link is opened in whatever browser you unblock the session in the DB. At this stage you can replace the login cookie with a real one, e.g. JWT, or continue using it as your main auth token.
If the user then returns to the real browser, you check the login cookie and act accordingly, keeping in mind that it may not be the browser where they validated the magic link. At this stage you can, again, replace the login cookie with your real auth cookie knowing that the session has been validated already.
I'm not entirely sure this is 100% safe, need to think about it more but at first glance it does look safe and seems to be pretty much the only way of handling magic links on mobile.
The Dynamics documentation is just awful and I couldn't find an answer to this simple question:
In the web version of the CRM, is it possible to register a web page that can be toggled by the user and that itself has an internal state (updated regularly by an interval set with setInterval) that will persist even if the users closes the page (not the entire CRM, just the sub-page)?
We need the user to provide some information for a CTI integration, and this background process to keep alive the CTI session by polling an API while the user session is active. In addition, we need to reuse the component where the user provides the CTI information to be notified if the session fails and restore it or close it if necessary. The real purpose for this is to make a screen pop (push content information about the incoming call to the agent) which I know can be done using Xrm.Utility, although doing it with a REST API method would be much better, RouteTo Aciton looks like the best method to do this, but I'm not sure it will proactively show the item in the user's browser.
I'm not sure this question is as simple as you suggest, it seems relatively complicated, and involves an integration. I'm not suprised the Dynamics documentation doesn't provide an answer for this specific and unique scenario.
I don't believe there is any single feature within Dynamics that will meet this requirement.
You could use a HTML web resource or a web page from a seperate web site iframed into CRM. I think the possible use of these depends on your expected user experience; I believe the user would need to have the page loaded at all times showing these controls (e.g. user is looking at a dashboard) - I don't see how the controls could interact with the user client side otherwise. You could show the controls in multiple places however.
Xrm.Utility is one way to open a record, but it can also be done by Open forms, views, dialogs, and reports with a URL.
RouteToAction looks like it just adds a record into the user queue, the user would need to refresh the queues to see the changes. I don't believe there is any way for a server side REST API call to natively redirect the user.
You could add JavaScript to do this, however you might struggle to add the JavaScript into every page of CRM.
Where I have worked on a CTI integration in the past (assuming you mean computer telephony integration), we always had some other component doing the screen pops - the client's all had a desktop app installed as part of the telephony solution.
Perhaps you could look into browser notifications, or a browser plugin?
I am almost finished with a SPA application using AngularJS and Bootstrap. So far, I got everything working as desired, except for one thing: Proper handling with the users acts on the Browser's back or refresh buttons.
All the sub-pages within the application have buttons/links to the pages the user may switch to. Still, the application should handle properly back and refresh browser buttons. I should add that there is a login process to enter the application.
Also, all the critical information is stored under $rootScope, so everything is lost when the user refreshes and, in some cases, when he acts on the back button the results are not as desirable.
I actually have two questions:
What is the widely accepted standard behavior of applications like mine when browser buttons are acted on? (remember, there is a login process to begin with).
How should I start tackling the implementation of this approach?
One option I was thinking, is to intercept the request, warn the user that the action will log him off, and if the user cancels, force the browser to ignore the request (not sure this is possible).
Client side routing, each view in the application should have a URL. This week allow the browser buttons to work as expected, and gives your users the opportunity to link directly to a view.
The most commonly used client side router for angular is angular ui-router - https://angular-ui.github.io/ui-router
What is the widely accepted standard behavior of applications like
mine when browser buttons are acted on? (remember, there is a login
process to begin with).
If you are using REST services,
Store authentication token in your local storage or in a cookie
When user refresh the page send a request to server and fetch user information
If the request result in 401 then show login screen
This is one of sample applications I have done with this approach.
Our intranet site has an unusual set of requirements.
It functions like a multi-page desktop application. For a single client, our users will be entering information on up to 30 screens.
It is an Asp.Net MVC3 based site with all session state disabled for efficient operation on a web farm.
For privacy reasons, we cannot use the query string to show any client information. We are currently using cookies to store client identification.
Our user base wants to have multiple tabs open in one browser (IE, FF or Chrome).
If I assume that the user is only going to be using a single, then I can store the client info in a simple cookie and everything works fine.
When the user opens a second tab, it would reuse the same cookie. Not the desired condition. So is it possible to determine the difference between the browser tabs?
You can use the sessionStorage object to store data specific to a single window/tab. It works just like any other JavaScript object, in that you can assign (sessionStorage.foo = "bar"), retrieve (baz = sessionStorage.foo) and delete (delete sessionStorage.foo), but unlike other JS objects any properties set will be persistent across pageloads in a single window.
The only downside is that it doesn't send this data to the server. You have to do this yourself using an AJAX call.
Look into the window.name variable. On page load you can put something unique in it, like the date/time, and store the same thing in your cookie (if its not present). If the user opens a new tab (or window), the value will be empty and the cookie won't be. window.name persists across page loads (if memory serves), so this will allow you to uniquely identify each tab.
This is in context to an ASP.Net application. The application makes use of a specific data which is set for a page. After this data has been set all the operations from this page onwards use the set data.
The problem is that if the user opens another tab with a competing data it overwrites the older data for the same session and for the same user which invalidates the operations on the first tab.
I know the suggested way is to refactor the code to remove such coupling but that is not possible. Here's another thread that discussed this but didn't specify any solutions other than refactoring the code (http://stackoverflow.com/questions/632062/ways-to-detect-ctrl-n-or-when-a-user-opens-a-new-window)
So, how can I detect (and notify the user) or stop the user from opening another tab - through javascript/Jquery?
You could set a session variable isActive and set it to true, along with all the other session data when the user opens the application the first time. After this, if the user opens another tab, check to see if isActive is true. If it is, inform the user and don't set the data again.
In pseudo-code, your logic should flow like this
if (!isActive)
//set session data
else
//alert the user: You have another active session
This would be a better solution because there is no guarantee the user does not visit the page to set the session, then temporarily turn off Javascript to launch a new tab without you being notified.
You should realize that you cannot prevent multiple pages being open on the same site by the same user. A user can always do such an operation using multiple different browsers on the same computer or browsers on different computers. As such, what you really need to do is to design your application to either just handle this situation gracefully or detect such a conflict and decide what the safest action is to take when it occurs (chances are, at the server, you either ignore the data from all sessions but one or you somehow merge them all together). What the safe action is depends upon what the data is or how it was changed.
The most straightforward option is to coin a new server-based session for the user each time the user visits and, at the server, invalidate all previous sessions so any older session that tries to make any future updates to the server will be denied because of an invalid session. This prevents any sort of multi-session data conflict.
If you want to be able to inform the user when their session becomes invalid, you could do a slow poll of the server (say once every 20 mins) as long as the window is open and on your site to check the session validity such that you can inform the user when their session has expired.