Win a copy of Escape Velocity: Better Metrics for Agile Teams this week in the Agile and Other Processes forum!

Jonh Smith

Ranch Hand
+ Follow
since Mar 18, 2010
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jonh Smith

This is probably a no-brainer and i'm just missing it but...what is the common way to have container FORM based authentication provide different FORM content to the user depending on the language ? What language ? well i guess that if was talking about the browser language then javascript would do, right (please confirm this is the best approach) ?...but i'm talking about the language that should be selected explicitly by the user for interaction with the site before login in (kept in a non authenticated session, a cookie, or what ?)

What's the approach people commonly use for this problem ? Thank you.

12 years ago
figured it out: it should be
${mytags:localeString(language, "navbar.menubutton.label.users", "")}

not

${mytags:localeString(${language}, "navbar.menubutton.label.users", "")}
12 years ago
JSP
Hello.

I have a tag file defined like this:



localeString is an el function defined in the tld like this:



when it tries to compile the tag file, the container ( glassfish 2.1) complains line this:



Can anyone help me by telling me exactly what am i doing wrong ? is it illegal to use an el expression as a string parameter of an el function ?

Thanks
12 years ago
JSP
Thanks David! I will look into it.
12 years ago
Just to share, the solution i came up with was to manage my own authentication information in a hashmap stored as a servlet context attribute.

1. https servlet trigers the container login prompt,
2. login ok => https servlet creates a UUID and stores it in that hashmap as the key to an UserInfo instance containing : the username (getUserPrincipal), role (isUserInRole(...)) and the uuid itself.
3. https redirects to http frontcontroller, having the uuid attached as parameter.
4. http frontcontroller reads the uuid parameter, retrieves the respective Userinfo from the global hashmap (stored in servletcontext) and if it finds it, creates a new session (request.getSession()) and stores this Userinfo as an attribute "uuid" of that session, to enable programatic authorization further on.
5. front controller forwards to pages inside WEB-INF, hence not directly accessible by the client.

the lifecycle of the userinfo in the hashmap is connected with that of the http session because I created a HttpSessionListener that overrides the sessionDestroyed method to remove the entry in the hashmap having the same uuid stored in the session to destroy.

there is also a ServletContextListener to create the UserInfo hashmap and insert it as an attribute of the servlet context.

So, that was my first solution. Anyway, I ended up concluding that the info I was planning to provide via http, is actually sensitive enough to justify the ssl overhead... :)
12 years ago
Is there any way to share a httpsession between the confidential and the non confidential parts of a web-app, without resorting to url rewriting ?

The question relates to the fact that whenever I do sendRedirect to an http servlet from inside an https servlet (one having a url with the CONFIDENTIAL transport-guarantee) , any session that I created inside the https servlet is not propagated, since the browser does not send any jsessionid generated by the https servlet (with request.getSession) to the http servlet in the same app, either due to the fact that the cookie is set with the Secure attribute in the first place or due to the http and https running in different ports not being recognized as the same app by the browser, or both.

More generically, what is the standard way to make a user access non-confidential content only as a securely (confidentialy) authenticated user ?

Thanks.
12 years ago
I wasn't very happy with hard-wiring the domain name so googled around and made a small change to your suggestion:

Thank you very much for your help!
12 years ago
JSP
Hello

I have a servlet protected with <transport-guarantee>CONFIDENTIAL</transport-guarantee>, which correctly makes glassfish generate an automatic redirection response to the https port, when i use that servlet's mapped url in the browser. However, once there, any redirection to some unprotected resource keeps using the htpps protocol, not http and i don't want that. How can i do a response.sendRedirect(/*WHAT DO I PUT HERE?*/) that acomplishes this ? That is, if i use



the server response redirect location is for
https://localhost:8082/mywebapp/myurl,

instead of
http://localhost:/8081/mywebapp/myurl

Thank you
12 years ago
JSP
Haven't read #4.

Recommend #2 (highly!!!) and #3. they complement each other.

Would not recommend #1. Superficial and buggy.
yes, the returned entities are not "managed". they are to be dealt with as pojos.
This is ok as long as the security environment of the presentation machine is sufficient and you actually use a reasonable amount of the returned User info. Otherwise if it may become a performance and/or security issue, a DTO that hides the sensitive stuff (i.e. password) and sticks to the bare minimum User content should be the way to go instead.
yep. if it is indeed BMT, #2 is correct, but then "bean-managed + requires new transaction specified" makes no sense as it is saying the bean is (BMT+CMT). so basicaly, if the bean is BMT #2 is correct. if it is CMT, #1 is correct.

But... if bean1 is cached, and a particular method of bean1 takes a while to process, then any other thread using bean1 will have to wait for that method to complete before any other method on the bean can be invoked.



for stateless beans, the container creates a thread served by its own bean instance, for each call to a business method. the reference you get is not to a bean instance but to a proxy that delegates each call to a separate instance of the bean you programmed. so no problem in caching this reference.
If I understood your point #1 would actualy be the correct answer.

The spec says about this:

17.6.2.10 Handling of getUserTransaction Method
If an instance of an enterprise bean with container-managed transaction demarcation attempts to invoke
the getUserTransaction method of the EJBContext interface, the container must throw the
java.lang.IllegalStateException.

let me see if i get this right...

As you know, the ejb spec was designed from the ground up to fulfill the commercial holly grail of software engineering - the supermarket of sw components; where an application assembler could go through the shelves filling his cart with the fresh beans of the season grown by ...yep bean providers :) and then hand it (sell it) to organizations where deployers would install the app in an environment given by one of many container providers, and so on ...

In practice, in many organizations (if not most of them...but this is just a gut feeling), a lot of the ejb roles are performed by the same person, wearing different hats, sometimes without even being aware of it.

This separation of roles led to the need to create mechanisms that while isolating the responsibilities of each role, would still allow communication to take place between them. So in this particular case, when you create a bean, you tell the application assembler (and in the case of security metadata, the deployer too, but that's a different matter...) which resources your particular bean uses, without knowing the actual names they will be associated with when the application is actually assembled.
So you, while wearing the enterprise bean programmer's hat, must use "local" names for the external resources your bean uses, whether they are other beans, data-sources, jms destinations, you name it. The application assembler (yep that's you again!) links your references to the actual beans, in the deployment descriptor.
The container ensures that when your bean is instantiated, it has its own jndi environment, where all the resources you declared as references in the dd are available under the tree "java:comp/env" accessible via the Context created with InitialContext() - no params. The spec suggests you use the prefix "ejb" for the ejb references so that an ejb, local or remote, is accessible using "java:comp/env/ejb/<BeanName>" but you don't have to (as your example shows). There is one such "Enterprise Naming Context (ENC)" - refer to the link i sent you - per ejb instance.

For remote beans your bean may act like a standalone application and retrieve remote ejbs through their jndi name in the GLOBAL namespace (which the ejb 3.1 finally standardizes) where they reside associated with the names you provide in the jboss.xml. Local ejbs do not work that way (in glassfish 2.1 for instance they don't even show up in this jndi tree) so you have to access them through the ENC (which you should always do in the first place for the beans that you reference, may them be local or remote - as long as they are in the same jee app).

The definite reference about this subject is chapter 20 "Enterprise Bean Environment" of the ejb 2.1 spec. You may also look into the equivalent chapter 16 of the 3.0 spec.

The link about the jboss stuff also seemed quite exhaustive and although I only skimmed through it would still recommend it.