1 Reply Latest reply on Aug 26, 2010 9:42 PM by Tim Evers

    Bookmarkable url's

    Mohan Radhakrishnan Newbie

      We know that all web applications require friendly url's that can be bookmarked. We don't use Seam but I wanted to ask the community how they would implement these url's in a normal web application.
      We have used WebSphere portal in the past and the portal framework has lots of framework code and security features to implement friendly url's. Now we have a non-portal web application.

      How is this done in a web application ?

      1. Do we allow these friendly url's to bypass the role based security and hit the web app. directly ? There is no single sign-on because these are bookmarked url's. Even if a normal user accesses a bookmarked url the requirement is to allow him access first. If we encode state in these bookmarked url's the state will become stale.

      2. Do we segregate the controllers ? If a hacker gains access to a friendly url sent in a mail or bookmarked he should not cause harm.

      3. Do we temporarily downgrade the permission of the user until an sms is received by the user with a different session password ? This session password could be used to upgrade the permission again. SMS features are costly.

      What are the thoughts about this ?


        • 1. Re: Bookmarkable url's
          Tim Evers Master

          Fix the app to work properly as a secured application.

          If unauthorised people need to see some data then here are some ways that is possible. (I'm not security expert but, the whole concept of letting unauthorised ppl get into the app via a link sounds mighty dangerous).

          1. Put all the pages that outside users can see in an unsecured area.

          2. Instead of going to the app directly from the link you give them a report (could be html) that was generated. This would work relatively fine. (Think of a frame that makes it look like the actual app from a guest user's perspective but with the content frame having the report content)

          3. You just make people log in when they click on the link and then redirect to the appropriate spot. (This is generally the accepted way of doing things).

          If you go down the track of allowing unauthorised users access to the system using some magic permission hacking you are gonna end up with users that get really frustrated especially if they have more then one window open. They'll be doing supervisor work in one window, click on a link they just received and magically behind the scenes they are now just a pleb with no permissions at all. While the page pointed at by the link is loading they go back to their supervisor work and find out when they hit a button that they are no longer authorised to do they work they were doing.