Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Refresh the page jsf, Get the URL of the current page  RSS feed

 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I want to refresh a page that is unknow, meaning it can be any page on the website with any numbers of parameters. I know I just have to do:



However I didn't manage to get the correct URL with parameters etc.

with this im close but params are missing:



I could get the param map and concat them but I don't know the numbers of params since it can be any page. I don't understand why something so trivial has to be that hard.
 
Tim Holloway
Bartender
Posts: 18661
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cedric Bosch wrote: I don't understand why something so trivial has to be that hard.


Because JSF is based on the Model/View/Controller paradigm, and HTTP/HTML is only the popular infrastructure for it, not the only possible infrastructure.

Also, because of being based on MVC, HTML parameters are not the normal way to work with data. JSF is primarily intended to work with Model (backing bean) data. When I want to bounce from View (page) to View, I don't load up URLs, I put the data into a backing bean (typically via session or FlashScoped where the new View can use it as its rendering Model.

Beyond that, you seem to be wanting to set up some sort of generalized transfer mechanism, but I can't determine what practical use it would have.
 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:

Beyond that, you seem to be wanting to set up some sort of generalized transfer mechanism, but I can't determine what practical use it would have.

It's to not maintain two log in functions.

Basically I've two scenarios to log in users:

1. unauthenticated user access a page that is protected he is redirected towards a login page. When logged in he is redirected towards the page he primarily tried to access.
2. unauthenticated user clicks on a button on my page that if the user is unauthenticated will display a log in modal dialog.

For the first method, assuming the user logged in correctly he is redirected as such :


The hiccup is that I'd like to have only one signInUser() function to maintain. Since I redirect for the first method I have a return type String. Since I've a return type String I need the url to correctly refresh the page for the second method.

I can do it if I have two log in functions. But I mean, I'm so close to have only one lol.



Tim Holloway wrote:

Also, because of being based on MVC, HTML parameters are not the normal way to work with data. JSF is primarily intended to work with Model (backing bean) data. When I want to bounce from View (page) to View, I don't load up URLs, I put the data into a backing bean (typically via session or FlashScoped where the new View can use it as its rendering Model.


Well you still load the get parameters in the bean to look into the db most of the time. I mean like /user?username="test". Then you lookup into DB for user called test. Here however I tried to call getRequestParameterMap() and then concatenated it to the returned URL. But of course the getRequestParameterMap() returns a whole lot of other params (so I don't know when to stop concatenating).

But I guess I'll just work around this. It just irritated me quite much I didn't manage to refresh a page from a returning String method. I'll just have two different methods and have a third one for the real log in business, so really it's no big deal. Thank you.
 
Tim Holloway
Bartender
Posts: 18661
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's a better way. Don't write your own login code!

I'm serious. I've worked with J2EE/JEE since before JSPs were invented, seen who knows how many webapps, including some critical financial apps and even some military stuff. And virtually every one that employed user-designed login processes had major security loopholes. Not excepting those designed by the shop's Resident Genius and mandated by corporate standards.

J2EE has a security framework built right into the spec and even the minimalist J2EE server implementations provide it. It's known as Container-Managed Security, because the bulk of its functionality is handled by the container, which manages the login (authentication) and authorization of user URL requests. Unauthorized requests are bounced by the container without getting anywhere neat the intended victim application, so you don't have to worry about possible security exploits in application code. In addition to basic authentication, the framework also provides Role-Based Access Control (RBAC) where a user can be assigned one or more security roles and granted or denied access to specific URLs within the webapp. All of which is configured in the web.xml file, which, being declarative, rather than code, is much easier to validate and much harder to mis-code.

You don't need any login logic at all using Container-Managed Security. You simply define the login mechanism (BASIC, via client dialog) or FORM-based (via HTML or JSP FORM pages), and in the case of FORM-based authentication, define the HTML or JSP template used for the login page (use of more complex technologies, such as JSF for login forms is not recommended).

You then match a security Realm to the webapp when you deploy it. The Realm defines the mechanism and location of the security database that contains the valid userids/passwords and userid/role mappings. It can be LDAP, JDBC, an XML file (such as the tomcat-users.xml) or just about anything. I''ve written custom Realms that used Web Services, there are single-signon tie-ins to Windows Authentication and so forth.

Once the app is deployed, every incoming URL is scanned against the secured URL patterns you define in web.xml. If the user requests a secured URL and is not currently authenticated (logged in), then the request is immediately sidelined and the user is prompted to login. The server will continue to prompt for a valid userid/password until it either receives on or the user gives up and goes away. If the user supplied valid credentials, then the sidelined URL is then resumed automatically as though login had never intervened. Except that now incoming HttpServletRequests will have the user's login ID in the getRemoteUser() method instead of null like an unauthenticated user does.

In the event that an authenticated user attempts to request a URL for which that user isn't assigned an allowed security role, then the server will block the request and display the 503: FORBIDDEN page (you can customize this page in web.xml).

Other than that, it's all magic. You can use a test Realm to avoid having to recreate (or worse, yet to use) the production security services without changing a single element of the WAR. And this same mechanism works virtually identically for all J2EE webapps regardless of what framework (if any) they employ.

One small caveat for JSF, however. Since the mechanism is based on the URL, and JSF URLs tend to lag behind the resource paths being employed, you need to add a "redirect" to the JSF navigation process for any View which navigates to a secured View. That will cause the URL to track and the proper security context to be applied.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!