If F5 is pressed after a POST request has been issued, browser will ask, whether the user wants to resubmit the post data. However, if redirect follows the POST request, no dialog appears. Is it possible to disable that dialog for a single page without redirecting the user?
No, this is built in behavior of the browser and can't be overridden.
Redirecting after the post is the easiest option to avoid the effects of reposting, there are other options to avoid issues with reposting but if it is to the same URL, you will still get the browser dialog.
Related
I have a link on my page that redirects to another page but the request is sent through POST method. Now when the user refreshes the new page the request is sent through GET method. The URL is just used to display a page. My question is, is it advisable to use both POST and GET for the same URL call or will it cause problems related to security or any other? If so please do explain how.
No. Use POST if the link is executing an unsafe action (e.g. logout, change password) or it is sending sensitive data you do not want displayed in the URL (URLs are logged by default in the browser history and by many appliances, proxies and web servers). POST can also be used when a large amount of information is to be sent.
Otherwise use GET.
I want to restrict direct access to certain page in my application. Those pages can only be accessible if the user is redirected to those pages by the application.
All the redirections are done via ExternalContext#redirect(url) method.
User can use back and forward button, also can refresh the page by pressing F5 or via browser's refresh button. What I want is user cannot save, or bookmark URLs of some page, also cannot copy those redistricted URL and paste and go via address bar of the browser.
Followings are the cases:
Say, I have Page-A and Page-B.
Redirection is done to Page-B from Page-A.
User can go back to Page-A and can come again to Page-B by using browser's back and forward button.
User can refresh Page-B and he/she will stay in Page-B.
User CANNOT copy the URL of Page-B and access it later time (in new tab or by bookmarking).
Is it feasible? Any pointer would be very helpful to me.
I don't think you can do all that from JSF.
Your obvious alternative is to use Javascript.
I never herd a concept of disabling Bookmark option in Browser using Javascript. However you can always disable the address field if you open the page in new Window.
You can solve it with
JSF Navigation Handler - set a session attribute from some previous page and expire the value after some time with a timer. From the Handler impl check the value of the attribute and restrict access e.g. redirect to some other page in case the value is not present.
You can achieve similar behaviour with web frameworks. Enforcing controlled navigation is a basic feature in most WEB FXs e.g. JBoss Seam conversations or Spring Web Flow controlled navigation implementations.
Whenever browser back is clicked, it must not navigate to the previous page but to some default page. how is it done using JSF ?
Clicking on browser back button requests the result page from the browser cache.
This is a client side activity. It doesn't send request to your server for fetching some default page(in your case).
Please refer this post for writing a filter indicating the browser not to cache dynamic JSF pages.
And also you can refer this one for more details.
You can try to detect if User has clicked on browser back button by writing client side code.
Refer this post for detecting back button click.
If you are trying to alter the behaviour of browser back button, it indicates some kind of flaw in your application.
I have a great working chrome extension now.
It basically loops over a list of HTML of a web auction site, if a user has not paid for to have the image shown in the main list. A default image is shown.
My plugin use a jQuery Ajax request to load the auction page and find the main image to display as a thumbnail for any missing images. WORKS GREAT.
The plugin finds the correct image url and update the HTML Dom to the new image and sets a new width.
The issue is, that the auction site tracks all pages views and saves it to a "recently viewed" section of the site "users can see any auctions they have clicked on"
ISSUE
- My plugin uses ajax and the cookies are sent via the jQuery ajax request. I am pretty sure I cannot modify the cookies in this request so the auction site tracks the request and for any listing that has a missing image this listing is now shown in my "recently viewed" even though I have not actually navigated to it.
Can I remove cookies for ajax request (I dont think I can)
Can chrome remove the cookie (only for the ajax requests)
Could I get chrome to make the request (eg curl, with no cookie?)
Just for the curious.
Here is a page with missing images on this auction site
http://www.trademe.co.nz/Browse/SearchResults.aspx?searchType=all&searchString=toaster&type=Search&generalSearch_keypresses=9&generalSearch_suggested=0
Thanks for any input, John.
You can use the webRequest API to intercept and modify requests (including blanking headers). It cannot be used to modify requests which are created within the context of a Chrome extension though. If you want to use this API for cookie-blanking purposes, you have to load the page in a non-extension context. Either by creating a new tab, or use an off-screen tab (using the experimental offscreenTabs API.
Another option is to use the chrome.cookie API, and bind a onChanged event. Then, you can intercept cookie modifications, and revert the changes using chrome.cookies.set.
The last option is to create a new window+tab in Incognito mode. This method is not reliable, and should not be used:
The user can disallow access to the Incognito mode
The user could have navigated to the page in incognito mode, causing cookie fields to be populated.
It's disruptive: A new window is created.
Presumably this AJAX interaction is being run from a content script? Could you run it from the background page instead and pass the data to the content script? I belive the background page operates in a different context and shouldn't send the normal cookies.
I got a solution for Firefox and IE but I didn't find any solution for Google Chrome.
Is there a way to do it in Google Chrome?
I know it's a really old post... I mean like friggin 5 years now, but I just found a somewhat good solution.
Inside your protected folder, create another folder, let's call it "logout". Place the same .htaccess file in here as you have in your protected folder, except with a small modification.
instead of:
Require valid-user
now write:
Require user EXIT
And make sure, you don't have a user named exit! :D
In your protected area, your logout link or button or whatever, should redirect the user to this address: example.com/protectedFolder/logout
The browsers usually are able to keep only one user logged in from one site name or realm name... the sign in attempt for the user Exit will overwrite everything, thus the originally logged in user, would have to log in again to the protected area.
But as always, I might be wrong, and you should still close all your browser window, and restart the computer if you want to be sure! :)
Also, it wouldn't hurt, if you would tell your users what is going to happen, when they hit logout!
I have tested this in chrome and in internet explorer 11.(will not work in edge, and maybe others neither)
The solution was found here:
https://www.mavensecurity.com/media/BasicAuthLogOut.pdf
You can't logout a HTTP authenticated session other then closing the browser window. Also see the accepted answer on this question for an extensive explanation.
try redirect to:
wrong_user:wrong_password#yourdomain.com
I have put together the following article which explains how I have managed to achieve this in Chrome. I hope this helps. https://www.hattonwebsolutions.co.uk/articles/how_to_logout_of_http_sessions
In short - you create a sub folder (as per Gyula's answer) but then send an ajax request to the page (which fails) and then trigger a timeout redirect to the logged out page. This avoids having a secondary popup in the logout folder requesting another username (which would confuse users). My article uses Jquery but it should be possible to avoid this.