Block Direct Browser Url Access in a Page
December 15, 2014 at 12:39 pm #26610
Hi. My webapp is in JSF 2.1, Primefaces 4 and the Rewrite Engine.
What i would like to know if its possible to block a direct page access with some config.
For example, i have a page with id “panel”, and the pattern is …/panel. So this page can only be accessed if the action comes from a p:commandButton or p:commandLink, but if the user try to access it directly by typing in the browser url it is redirected to home with a “403” message.
I’ve saw some examples, like get that request parameter from a forward:
String originalURI = (String) externalContext.getRequestMap().get(RequestDispatcher.FORWARD_REQUEST_URI);
But it returns null.
So, is there a way to know from where the forward is coming from? Or block the access if the forward dont come from a button?December 16, 2014 at 12:29 am #26616
Sorry, I don’t understand what you want to say with:
So this page can only be accessed if the action comes from a p:commandButton or p:commandLink
Clicking command buttons will result in regular HTTP requests. The only difference between regular postbacks and an user entering the URL into browser bar is the request method (POST vs GET). You COULD build a Rewrite rule to detect GET requests. But they will also be triggered, if you click on some h:link that points to the page.
Again, I’m not sure what exactly you are trying to solve. Perhaps some code examples would help to clarify your usecase.December 16, 2014 at 3:14 pm #26624
Hi Christian. First of all thanks for your answer.
Even you saying you’re not sure, you got the point and gave an idea.
My webapp is almost full ajax, with few “h:links”, so that idea of blocking get requests is interesting.
Now let me try to clarify my usecase, i have a mapping /home, in this page there is a list of “objects”, and each row has a p:commandButton (ajax) with an action that prepares the next view /panel and returns a “pretty:panel” that redirects to the /painel page and show that object info.
And thats where i would like the “blocking”, i dont want the user to type https://mywebsite.com/painel directly in the browser, i want just allow users that clicked that p:commandButton in the /home and got redirected to the /panel.
Was i more clear now?
And following your idea, that was another question, my project has the rewrite maven entries, but i dont think im using it fully, i think im just using the prettyfaces, i have a prettyconfig.xml file and the default configuration.
Could you give me an example of that “GET request blocking”?
Obs: Sorry about my english, still learning.
Thank you very much.December 18, 2014 at 1:41 am #26649
I don’t think that it is possible to do what you want.
If you click a commandButton and return “pretty:panel”, the server will respond with a redirect to the client. This tells the client “Hey, please request
/panelwith a GET request”. The browser will then do this and request
/panel. But this is a standard GET request. If the user manually requests the page, it will also be a GET request. So there is no easy way to distinguish the two.
If you really want something like this, you will have to implement something manually. You could for example generate some random number in your action method and include this in the redirect URL. You will have to replace
/panel.xhtml?faces-redirect=true&randomNumber=234234234(which is basically the same thing but includes the additional parameter). The panel page could then verify if the random parameter correct. You could for example store it in the session for this check.
However, I’m not sure if all this is worth the effort. But that is just my personal opinion. Basically I think that all URLs should work independently. That’s one of the main goals of PrettyFaces. 🙂December 19, 2014 at 6:40 am #26663
Hi Christian. Thanks for your reply again.
That’s what i did, a simple session control with a variable, i just asked because i though it could be done in a more “elegant” way, but its ok, its working anyway.
And i agree with you, the URLs should work independently, but in my specific usecase, this “simple” control saves me from a lot of problem.
Thank you very much.
You must be logged in to reply to this topic.