I have a Single Page Application (SPA) built with DurandalJS v1.2 that integrates with a payment gateway. The SPA will go off to the payment gateway's page by doing a normal form POST to their page.
Once the user has finished on the payment gateways page, the payment gateway will then do a form POST back to my SPA.
Since it's a POST, I handle it server side in ASP.NET MVC by rendering out a require.js module definition for the various form parameters being sent, and this module is then used in the view model that needs to handle the result.
This is all working fine, I handle the result, and then stay on the same SPA page. This is different to the typical web pattern of Post-Redirect-Get, since the SPA doesn't do any redirects.
The issue now is when pressing the browser refresh button, it's bringing up the browser's retry post confirmation dialog (which I don't want).
Is there a way to avoid this by using JavaScript, or is the PRG pattern the only way?
Note: It appears that changing window.location, document.location, as well as using history.replaceState all do not work (at least in Chrome).
If you can modify the payment gateway, then intercept the form submission (<form onsubmit="...; return false">), process the form fields from JavaScript instead of letting the browser send them to the server.
If you can't modify the payment gateway, then modify the document.location from JavaScript just after the POST back (e.g. by adding a #). If the user presses reload after this, the browser won't ask for confirmation.
Related
A user tries to navigate away from a page, either by following a link, or submitting a form.
I want to do some server-side validation on HTTP requests before I allow them to proceed. If validation fails, I want the user to stay on the same page and get some notification.
Can the server generate a response that will make the user stay on the same page?
For example, I was thinking to use a Content-Disposition: bogus header to stay on the page (and a hack to get the validation failure), but apparently browsers try to save those responses to a file, as if the were attachment, instead of ignoring them.
I can inject javascript into the web pages, but the page logic is a black box for me (I can't write client-side code that's specific to the logic). So, I can't reimplement forms and links on the page as AJAX calls.
This is a bit old school (web forms). My Asp.Net site uses FormsAuthentication for security with the typical settings for forms authentication in web.config. This works well. User logs in and is authenticated via back-end logic in business layer. So, now I have created a "back door" login technique using a simple form that posts user/pass via jquery ajax to the exact same back end logic code.
In both login scenarios, cookies are created, and in fact, comparing the two shows them to be identical. But, my problem: I log in via the jquery ajax, then when I go to my forms authentication protected page, I am redirected to the "log in page" as defined in web.config. If I reverse the situation and log in via the formsauthentication WebForm, then I AM successfully recognized as "logged in" at the jQuery ajax form.
I've tried so many things I am now confused. Path, domain, HttpOnly, Secure, etc.
I don't have code to show, but can if needed. I'm hoping this problem description might just ring a bell in someone's head.
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.
I am trying to implement form authentication in my ajax application.
The problem I have is that when the session expires I get 302 code which redirects me to a login page I specified in web.xml (and it messes everything up refreshing the whole app to login page).
What I want to do is to get a "not authenticated" (401) code, then display the login form in a popup window and when the login is successful continue with what I was doing.
here is a picture of what is going on:
and the docs
http://docs.oracle.com/javaee/1.4/tutorial/doc/Security5.html
basically, I want to display the popup instead of redirect to login page and then don't do the redirect to the resource but do my update in AJAX way.
From what I understand it couldn't be done only on the client side since the redirect can't be avoided (see here: redirect info), I would need to write some kind of logic on the server to prevent redirect, see here for detail about doing it in IIS: IIS implementation
P.S. So far this: http://www.oracle.com/technetwork/articles/entarch/session-lifecycle-096133.html looks like the most promising way to implement it. The class is deprecated, but I can't find the new one and think it's the only way to do it for Weblogic.
This is not an easy way but still it works
You have a form in your page which is filled by the user.
User clicks submit button.
An ajax request is sent to the server.
The server side implementation can check whether session exists or not. and accordingly you can send a response code 401..(response.setStatus());
This 401 can be checked in client side using ajax --- xhr.status
If response is 401 you can show the login form and hide the current form. using js and css.
User fills in the login details and clicks submit..
You can do the same server side check and client side check for the status of that login request.
if login is successful then you can you can submit the first form using ajax or js..
You may need to use servlet authentication filters as described in weblogic.xml Deployment Descriptor Elements
Below tutorials may help you:
oracle Servlet Authentication Filters
Using servlet filters for user authentication
Writing Servlet Filters
You could use a heartbeat checking with an ajax request to your server to any resource that needs to be authenticated to get it.. if you cannot receive this resource so means that youre not logged in.. so you could send another authentication request an go on with your rendering..
see this article.. http://ajaxpatterns.org/archive/Heartbeat.php
so your checking routine of authentication would be implemented..
You need to push to page and not poll. So you need Strophe and your session handler connected. When session expires signal is sent to Strophe instance that is running in your web app and after that it is easy to do popup or whatever.
For all real time stuff I am using Strophe!
This is book on this metter and this is link for Strophe, also this is link of php xmpp class.
It will take you couple of days to figure out this but it is couple of days well spent!
If you read carefully book and go to examples, with just basic javascript/jquery understanding you will be able to develop powerful web apps.
I know you're trying to do FORM authentication with you ajax application but is it really needed?
BASIC authentication works simpler and transparently for ajax requests as it is handled by the browser, not by your app. But I admit/understand that a popup is ugly.
I'm building a Single Page Application, read that login page should not be on the same page. Should I have login as a separate html page, or can I have login also in the same page.
If I have login as a different page, depending on the first page that I load should have to redirect to the other in client side.
ie suppose I load the SPA first, and if the user is not logged in, I've to redirect to login page in client side. and suppose I load the login page first, and the user is already logged in, I've to redirect to SPA in client side.
What is the general solution for this problem?
I'd put login and verification in a separate page and then use ajax to make the calls.
User access index-file.
Index-file makes checks with server-side page to see if user is logged in or not.
Page displays content depending on if the json answer from the server-side page was true or false.
Then I'd do the same for logging in.
User provides login information
Checks with server-side file through ajax and json.
Page refreshes if succesful or throws error response if it's not.
The bottom line to my answer is that when creating single-page applications, ajax is the way to go. However, since you havent provided what language you're using, i'm unable to give you a more detailed answer.
Client side single page handling logins and content selection however is very bad practice and should be avoided all-together because of their lack of security (I cant stress this enough) since all elements will be available even to anonymous access and DOM manipulation will enable an unauthorized user to access restricted content. You'll have to use ajax to do backend serverside authorizations - as mentioned, as well as serverside code on the SPA that present different content depending on your authorization status.
The scenario you describe need to have server-side code for selecting what content to present and client-side code together with ajax for implementing features on the SPA.
What you CAN do however, is to - when for example pushing the login button - calling another file with ajax, remove the content of the wrapper div and append the ajax response to that div. Then you'll avoid client side redirections all together.