How would i go about checking if a person is refreshing a jsp page? Could we make it for example that every time we reload a page we would first check if this happens and then we check with System.out.print().
Hmm, first System.out.print is of little use in a JSP because it will never reach the client. At best it will end in the logs, at worst it is lost.
Then in simple cases you can trust the HTTP Referer header that is supposed to give the previous page url. But it is an unreliable way because it may not be transmitted by the browser. A more reliable way is to use a session variable to store the current page (you could use a filter to set it after a request is being processed). If the requested page is the current page, then it is being refreshed.
In complex use cases (AJAX requests) you should first define what is a page, because not every request will constitute a page: some will call a page while some only ask data. But once this is clear, you can apply the previous way: if the user asks for a page which is the current page (as stored in session), then the page is being reloaded.
If you want to do something every time a page load. Then you can use simple javascript for that. Try this
window.onload=function()
{
dosomething();
console.log("Page is loaded");
}
You can learn about it from here.
https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onload
Related
So there is an error.jsp page and I want user to occur on this page after he/she inputs invalid data.
Is it better to use sendRedirect or requestDispatcher.forward for redirecting to the error page?
I know, it may depend on whether I want to put some attributes to the request object and so on. And I'd prefer to use requestDispatcher.forward, but is it safe? Cause in this case after page refreshing the data will be sent to the server one more time. Yeah, it doesn't make any effect (insert, update, delete) on database since the data is invalid so the user occurs at the error page once again. But... idk, I feel like something is being wrong with the approach of using requestDispatcher.forward, even though it's kind of idempotent action.
So what do you think?
The important difference is :
The function sendRedirect will send a 302 response code to browser, then the browser will send another request to server again
https://en.wikipedia.org/wiki/HTTP_302
but the function requestDispatcher.forward is a server internal redirection, The browser has no feeling about it !
I want to make a custom 404 error page.
Where customers, if they come on this page, have the posibility to send the broken url to us and when they have sended to us they see a discountcode.
So basicly i need a submit button that send the current url of the page, and shows a specific code afterward, but without reloading the page.
Who can help me with this?
Basically, you'll need three things to do this:
1) A custom 404 URL that will point to your 404.html page. This is configured based on your webserver-specific configuration, so you'll need to make some changes to point to this page.
2) An Ajax call on your 404 page so that you can make a request without reloading the page.
3) A server-side code generator that can generate and return a unique one-time-use discount code.
The Ajax is pretty easy to do. There are a number of different configuration / frameworks online that allow you to make a request without loading the page. At their core, they usually create a hidden IFrame DOM element with a form inside of it, and submit that form, then close the IFrame. You'll need to tie into this from the parent frame, having the form that submits get sent back the generated discount code from the server. You can then access this data from the parent frame, and display it to the user (probably using JavaScript).
One KEY piece of information to this is that your user could just type in some garbage (ex. http://yourdomainurlhere/oihoaiwhegaweg) and be redirected to a 404 error, and get a discount code. Once this knowledge becomes commonplace, people will always do that to get a discount code; thereby invalidating the reasoning you have for wanting to get the broken URL (in order to fix your site).
You can probably try to get around this by checking for referral links, etc., to try to determine if they actually clicked on a link on your site, or if they just arbitrarily typed in a URL. But this will take much more analysis and possible changes to your entire site to track URL clicking in order to generate the invalid URL.
Project Context
Client requires that the users of the site (when logged in and are able to view their personal information) be forced to be logged out if they try to navigate using the browser's navigation buttons.
My Research
Searching around on SO seems to indicate that most of the problems people have is to "stop" people from hitting the browser's back button when they're logged out, like this and this. The difference is that I need to "stop" the users from navigating backwards in history (and even forward as well, though I don't see how the users can go forward in history if they can't go back in the first place) even when they are logged in, making it compulsory that they use the provided navigation.
The Solution I Have In Mind
I'm thinking of capturing the browser's event when a user hits the back button and logging them out then. However, as discussed here it seems like you can only "do it" using Javascript and not using server-side code. My qualm with this approach is that users can bypass it merely by disabling Javascript on their browsers.
My Question
So my question is - Is there a way I can capture the browser event on the server-side and log them out there? If not, what are the alternatives to achieving my objective?
I'd say that your best option is tracking the session.
You make the client send you the timestamp of when the request was processed by your server, or even simpler: a user dependent counter (which you send each time to the client), and server-side keep track of the last timestamp/counter sent.
If the user clicks the back button, he will send you an old timestamp/counter instead of the last current one, and you can then log him out server side.
This should do the trick.
In order to make sure the trick is done and making it javascript independent, I'd say you could place this value in a hidden parameter, or maybe as a hidden field form, so the user doesn't see it but it always gets sent to your server.
I hope this helps!
What I did was to create a single page, 1 html document, then use AJAX to navigate the whole site. When a user hits the back button it takes you to the index page, which is the log in page. To log in I use AJAX which I do redirect on the server side only. The only problem is when a user hits the forward button but the good thing is no JS no navigation.
If the requirement is trap browser navigation buttons and log them out - the easier alternative is never show these navigation buttons in the first place. What is the use if the user cannot use or click back and forward.
Open a new browser without a toolbar, menu bar from you webapp. When the user closes the window, trap the event and logout the session. This way - the solution would remain simple.
My 2c
Relying on javascript is not a good practice, since it is on client side and what runs on client side can always be bypassed by client.
You should instead use session timeout.
Sorry, fetch the buttons themselfe isnt possible.
Since this is a security-problem a solution (without javascript) would be:
to use encoded pages who warn on navigation out-of or into an unencoded-page. Even the mutual authentication might fit your needs.
If I understand correctly your question:
You can't avoid the user to send a request to your server, the user has full control of his/her browser unless you want to ship a custom altered version for an intranet crew (from open-source browser projects).
Without javascript the the only thing you can do is to send a specific parameter via GET when clicking in the required nav button. If the parameter is present you allow the view of the next/prev page, otherwise the user is logged out.
Obviously the user can bypass that by using the browser developer tools. But there is no way you can fully control user UI behavior at this level.
If i am right then you are talking about NO-Cache in broswer.
you can set all these like following:
response.setHeader("pragma", "no-cache");
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Cache-Control", "no-store");
response.addDateHeader("Expires", -1);
response.setDateHeader("max-age", 0);
response.setIntHeader ("Expires", -1);
prevents caching at the proxy server
response.addHeader("cache-Control", "private");
And then you can define a filter who checks session on every page. When a user logs in then set an attribute in session and on logout remove it.
I have a jsp page -- let's call it index.jsp. The user clicks on a link in this page -- let's call the link section1.jsp. Inside section1.jsp, there exists a form. When the user submits the form, it opens up another page called portal.aspx.
When the user clicks the back button in the browser, I want the page to go back to index.jsp.
My idea is this: Create a session from request.getHeader('referer') to record the index.jsp page. This will get set when the user enters section1.jsp. The idea is when the user is in portal.aspx and clicks the back button, I want it to check the session variable and, if it is set, redirect to the referer URL. Then I tried it and it didn't work.
Is there some way to accomplish what I just described, without the browser recording secton1.jsp in its history, such that the user will go to index.jsp from portal.aspx, when said user clicks the browser's back button? Please understand I'm looking for a server-side solution and I must use a form to open the portal.
Thank you for any help.
If you are going pure server side, there is no solution.
You may as an alternative use a cookie to store the return URL, this will ensure it doesn't get lost should your page flow change in the future. only issue, now your two back ends need to shate the same domain.
I would personally go with a little of frontend help, these are really API JS api to handle page history.
see https://github.com/browserstate/history.js
When the user logs out of the app and if user clicks on back button he will be able to view the recently visited page and do all the operations again,how to handle this in java?
You need to disable caching for your pages. You can do that by doing something like this:
response.setHeader("Cache-Control", "no-cache");
Read here for more details.
First thing first,
Store the user info in the session upon log in
Remove that info upon logout. You should also take a look at SessionListener, in the case of time based logouts
Every request from the user must go through a filter which checks the information stored in the session at log in time, if found give a go, otherwise redirect to login page.
Caveat: Back button will still work with GET requests. For that consider kgiannakakis's suggestion.
Best of luck.