How to keep a static URL in the address bar regardless of which page is open

[Frank Iii Manuel]

Hello,

In the interest of security (i.e. I don't want users to be able to type in the URL of a page to access it), I'm wondering if there's a way to keep the URL on the address bar static.

e.g. users access "http://ServerName/App" and reach the login page. And as they navigate through the application, the URL never changes and stays "http://ServerName/App".

Is there a configuration for this, either in JSF or in web.xml? If not, any alternative solutions to prevent direct page access via location bar?

Help is much appreciated.

Thanks,
Frank

[Osama Hamed]

any one knows the answer,
it is really helpful
thanks in advance

[Marco Ehrentreich]

Hi guys,

first an important side note: It's very insecure to believe that it makes a web application more secure when you hide the URLs. This offers simply almost no protection!!!

The answer how to hide URLs is basically POST requests - with all the downsides a pure POST application will bring you. But this way you can have one Servlet to respond to this "static" URL and you must give it all additional information for page navigation etc. with POST HTTP parameters.

But as I said this doesn't change anything regarding security!

Marco

[Tim Holloway]

Marco Ehrentreich wrote:... But this way you can have one Servlet to respond to this "static" URL and you must give it all additional information for page navigation etc. with POST HTTP parameters.

... And that "one Servlet" won't be the FacesServlet, which has its own ideas about what goes into a URL. So this approach fails for JSF apps.

Do-It-Yourself security is a really bad idea. Unlike "Hello, World", security isn't something that untrained children can do. The people who designed the industry-standard security systems are professional experts in security, some of them do basically nothing but security, they all get together and argue about exploits, run lots of test cases, open the standards up for field trials, run mathematical proofs ... and still have exploits turn up. Although in their case, it's usually several years, and the platforms are designed so that when it happens, there are ways to rapidly mitigate the problem without having to rewrite major system components.

"Clever" people are almost never as clever as they think they are. They make assumptions that only honest people are going to break in (which is kind of a contradiction), they don't know the common exploits, and they don't build on proven principles. As a result, most of the DIY security I've run into over the years has basically been nothing but soggy cardboard.

[Marco Ehrentreich]

I can only confirm what Tim wrote!

In fact it's not only security where self-made solutions often fall short. I've seen this for lot of others things too where "clever" people think they can come up with quick solutions for any complex topic which are supposedly better than any existing solutions which were created by hundreds of real experts all over the world.

Marco

[Ed Burns]

As Mahendra Pratap pointed out, you can use the redirect in your
navigation rules, but you can also use implicit navigation. For example,
in any ActionSource2 component (h:commandButton, h:commandLink, etc)

You can say <h:commandButton action="next?faces-redirect=true"
value="submit" /> and you'll get the redirect. This will cause the POST
REDIRECT GET pattern to be followed. I have a big section on this
starting on page 123 in the new book. This feature also works well with
view parameters.

Ed

[Lincoln Baxter]

If you want this functionality, while I don't recommend using it for your entire applications since (as mentioned previously) it will not improve security, you can use PrettyFaces dynamic View ID functionality to funnel all requests through the same URL:

http://ocpsoft.com/prettyfaces/docs/#dynamicviewid

(Click the link in my signature if you want more general information on what PrettyFaces does.)