I had the problem, that I had a FacesConverter like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

import javax.annotation.ManagedBean;
import javax.annotation.PostConstruct;
import javax.enterprise.context.RequestScoped;
import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.convert.Converter;
import javax.faces.convert.FacesConverter;
import javax.inject.Inject;
 
 
@FacesConverter(forClass = AvailableCountry.class)
@ManagedBean // does not help :(
@RequestScoped // does not help :(
public class AvailableCountryConverter implements Converter
{
	@Inject
	AvailableCountryDao dao;
 
	@PostConstruct
	public void postConstruct()
	{
		System.out.println("calling postConstruct");
	}
 
	public Object getAsObject(FacesContext facesContext, UIComponent
			component, String value) {
		if (value == null || value.length() == 0) {
			return null;
		}
		return dao.find(getKey(value));
	}
 
	Long getKey(String value) {
		Long key;
		key = Long.valueOf(value);
		return key;
	}
 
	String getStringKey(long value) {
		StringBuffer sb = new StringBuffer();
		sb.append(value);
		return sb.toString();
	}
 
	public String getAsString(FacesContext facesContext, UIComponent
			component, Object object) {
		if (object == null) {
			return null;
		}
		if (object instanceof AvailableCountry) {
			AvailableCountry o = (AvailableCountry) object;
			return getStringKey(o.getCountry().getId());
		} else {
			throw new IllegalArgumentException("object " + object + "
					is of type " + object.getClass().getName() + "; expected type: " +
					AvailableCountry.class.getName());
		}
	}
}

But my DAO was not injected, nor was the postConstruct method triggered by CDI.

Why?
Because the bean is not managed by CDI, not even when annotating it with @ManagedBean because it gets created by the JSF-Lifecycle and not by CDI.

Well.. but how to manually lookup a Bean with CDI / Weld?

First, you need to get the BeanManager. When you have a FacesContext (like in the converter above), you can get it like this:

1
2
3
4
5
6

    public BeanManager getBeanManager()
    {
        return (BeanManager) 
              ((ServletContext) facesContext.getExternalContext().getContext())
                   .getAttribute("javax.enterprise.inject.spi.BeanManager"); 
    }

If you don’t have access to a FacesContext, ServletContext or similar, you can lookup the BeanManager through JNDI

1
2
3
4
5
6
7
8
9
10

    public BeanManager getBeanManager()
    {
        try{
            InitialContext initialContext = new InitialContext();
            return (BeanManager) initialContext.lookup("java:comp/BeanManager");
        catch (NamingException e) {
            log.error("Couldn't get BeanManager through JNDI");
            return null;
        }
    }

After you’ve got your BeanManager, simply lookup your Bean like this:
(In my case, I wanted to lookup a bean with the type AvailableCountryDao)
Type-based CDI manual lookup

1
2
3
4
5
6
7
8

    public AvailableCountryDao getFacade()
    {
        BeanManager bm = getBeanManager();
        Bean<AvailableCountryDao> bean = (Bean<AvailableCountryDao>) bm.getBeans(AvailableCountryDao.class).iterator().next();
        CreationalContext<AvailableCountryDao> ctx = bm.createCreationalContext(bean);
        AvailableCountryDao dao = (AvailableCountryDao) bm.getReference(bean, AvailableCountryDao.class, ctx); // this could be inlined, but intentionally left this way
        return dao;
    }

Thanks to my friend Lincoln Baxter, III for the snipped.

Name-based CDI manual lookup

1
2
3
4
5
6
7
8

    public Object getBeanByName(String name) // eg. name=availableCountryDao
    {
        BeanManager bm = getBeanManager();
        Bean bean = bm.getBeans(name).iterator().next();
        CreationalContext ctx = bm.createCreationalContext(bean); // could be inlined below
        Object o = bm.getReference(bean, bean.getClass(), ctx); // could be inlined with return
        return o;
    }

So, now you’re able to manually lookup beans with CDI.
In case you have the same problem (with Converters/Validators) like I had above, checkout Seam Faces, where this problem already is fixed,
meaning your @ManagedBean annotated Converter/Validator is working as expected with @Inject, @PostConstruct & @PreDestroy

In our example, we want to match a URL like this one

1

http://www.studyguru.eu/at/tuwien/184.153--Entwurfsmethoden-fuer-verteilte-Systeme

Previously I tried to match it with a PrettyFaces Pattern/Regex like this:

       <pattern value="/([a-z]{2})/([a-z0-9\-_]*)/([a-z0-9\-_\.]*)\-\-.*"/>

But thankfully, PrettyFaces >2.0.4 supports directly populating the RequestParams!

Configure your pretty-config like this:

1
2
3
4
5
6
7
8
9
10
11

<pretty-config xmlns="http://ocpsoft.com/prettyfaces/2.0.4"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="http://ocpsoft.com/prettyfaces/2.0.4
                http://ocpsoft.com/xml/ns/prettyfaces/ocpsoft-pretty-faces-2.0.4.xsd">
....
 
    <url-mapping id="coursePage">
        <pattern value="/#{countryCode}/#{uniShortName}/#{courseId}--.*"/>
        <view-id>/path/to/coursePage.xhtml</view-id>
    </url-mapping>
....

and use JSF2′s viewParams like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
        PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:pretty="http://ocpsoft.com/prettyfaces"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:p="http://primefaces.prime.com.tr/ui"
        >
<body>
<f:metadata>
    <f:viewParam id="countryCodeId"
                 required="true"
                 requiredMessage="Kein Land spezifiziert"
                 name="countryCode" value="#{coursePageBean.countryCode}"
            >
        <f:validateRegex pattern="([a-z]{2})"/>
    </f:viewParam>
 
    <f:viewParam id="universityCodeId"
                 required="true"
                 requiredMessage="Keine Hochschule spezifiziert"
                 name="uniShortName" value="#{coursePageBean.universityCode}"
            >
        <f:validateRegex pattern="([a-z0-9\-_]*)"/>
    </f:viewParam>
    <f:viewParam id="courseIdId"
                 required="true"
                 requiredMessage="Keine KursId spezifiziert"
                 name="courseId" value="#{coursePageBean.courseId}"
            >
        <f:validateRegex pattern="([a-z0-9\-_\.]*)"/>
    </f:viewParam>
 
    <f:event type="preRenderView" listener="#{coursePageBean.populate}"/>
</f:metadata>
<h1>coursePage</h1>
 
countryCode #{ coursePageBean.countryCode} <br/>
courseId #{coursePageBean.courseId}<br/>
universityCode #{coursePageBean.universityCode}<br/>
</body>
</html>

Voila! You now can match complex urls with PrettyFaces and apply all your custom validators
to your Pretty URL

A LoginContext Object is used by applications to authenticate users independently of the underlying authentication technology. Authentication technology in this context means stuff like “file based authentication”, “Database based authentication”, “LDAP authentication”, “CERTIFICATE authentication” and so on.

The LoginContext class is part of the javax.security.auth.login package and describes methods used to authenticate Subjects/user in the meaning of Part 1 of this series). The documentation states:

A subject is an identity in a system that you want to authenticate and assign access rights to. A subject can be a human user, a process, or a machine..

which is basically what I said before. Its still a little bit unclear to me, why they use “user” in one documentation and “subject” in the other, but as its the same thing, we know what to do.

The documentation further states, that a subject may interact with different authorities (applications) and may have different passwords (credentials) for each of them. To represent the subject/user in these applications, the java.security.Principal class is used.

Our own LoginContext now invokes various LoginModules ( these handle the different ways of authentication, like form based, HTTP-Basic, HTTP-Digest, etc.). The LoginModule interface is part of
the javax.security.auth.spi package. If one ever wants to integrate Facebook connect or something similar, this is where to look at!

But how does the LoginContext know, which LoginModules to invoke? This is done by a Configuration Object.

So, to sum this up:

1. We have 1-n LoginModules, handling different form of authentication.. file, db, ldap and so on
2. We have a LoginContext, taking users credentials and supplying them to the LoginModules
3. We have configurations, specifying which LoginModules should be used by the LoginContext
4. A client supplies its credentials to the LoginContext. The LoginContext looks up, which LoginModules to use in its Configuration and authenticates the client with the provided credentials against the LoginModules.

But why bother with all this stuff of LoginContext, LoginModules, Configuration and so on? Shouldn’t it be easy to use authentication, especially custom authentication in a web-app?

Because we’ve already got it in our AppServer!

Configuration:
We’re actually creating our Configuration object manually in our web.xml.

Here we define, how we gain the authentication data from the user. In this example, I used auth-method=FORM because no-one wants to use HTTP-Basic Authentication anymore today!

    
        FORM
        nameOfTheRealm

/login.xhtml
/loginError.xhtml
        
    

With this configuration, you can already create your own login form with your preferred style, like this:
login.xhtml

1
2
3
4
5

<form method="post" action="#{request.contextPath}/j_security_check">
<label for="username">Userid</label><input type="text" id="username" name="j_username">
<label for="password">Password</label><input type="password" id="password" name="j_password">
<input type="submit" value="Login">
</form>

In the next part of the series, we’ll see how you can do it with an jsf/facelets page.

Ok, we now got our form for login. To Logout simply make a link to /j_security_logout

We’ve now got login + logout, but they are not working yet. What we still have to do, is specify, what we’re authenticating against. In this post, we called it LoginModule, in Glassfishv3 its called Realm and we have already
configured it with our Login-Config above.

A post which explains how to configure the simply, build in Glassfish “File-Realm” is available at DevelopInJava.com.

In the next blog entry of this series, we’ll see how we can create our own realm, that really suits our needs.

We now got everything needed for a basic authentication, but we don’t yet have a group to role mapping, which we need for stuff like #{request.isUserInRole(‘ADMIN’)} or annotating our beans (see later for all of that).
So what we’re going to do is, map the given “groups” to roles. Before we do that, we should tell our application, which roles we have. Do it like that in your web.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14

    <security-role>
        <description>all the users with the role Admin</description>
        <role-name>ADMIN</role-name>
    </security-role>
 
    <security-role>
        <description>all the users that are authenticated</description>
        <role-name>LOGGEDIN_USER</role-name>
    </security-role>
 
    <security-role>
        <description>all the users that are moderators/extended rights</description>
        <role-name>MODERATOR</role-name>
    </security-role>

Now we can map the groups we get from the realm to our roles. We have to put this in
/WEB-INF/sun-web.xml (if you’re using Glassfish v3). My file looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC '-//Sun Microsystems, Inc.//DTD 
Application Server 9.0 Servlet 2.5//EN'
    'http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd'>
<sun-web-app error-url="">
    <context-root>/</context-root>
    <security-role-mapping>
        <role-name>LOGGEDIN_USER</role-name>
        <group-name>default</group-name>
    </security-role-mapping>
    <security-role-mapping>
        <role-name>MODERATOR</role-name>
        <group-name>moderatoren</group-name>
    </security-role-mapping>
    <security-role-mapping>
        <role-name>ADMIN</role-name>
        <group-name>root</group-name>
    </security-role-mapping>
    <class-loader delegate="true"/>
    <jsp-config>
        <property name="keepgenerated" value="true">
            <description>Keep a copy of the generated 
                servlet class' java code.</description>
        </property>
    </jsp-config>
</sun-web-app>

Click here to view the general structure of the sun-web.xml file.

Our User -> Principal, Group -> Role mapping now works. We can start protecting resources in our app! Horray!

We’re doing this by specifying “security-constraints” like this in our web.xml

1
2
3
4
5
6
7
8
9
10

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>admin-area</web-resource-name>
            <url-pattern>/admin/</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <description>admins should be allowed to access this resources</description>
            <role-name>ADMIN</role-name>
        </auth-constraint>
    </security-constraint>

This should be quite self-explanatory, for a detailed explanation take a look at
Security Annotations and Authorization in GlassFish and the Java EE 5 SDK, which also explains how to secure beans with annotations
and has a nice matrix whats possible with annotations and whats not.

If you want to lock some stuff for everyone, simply leave the auth-constraint element empty, like this:

1
2
3
4
5
6
7
8

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>admin-area</web-resource-name>
            <url-pattern>/admin/</url-pattern>
        </web-resource-collection>
        <auth-constraint>
        </auth-constraint>
    </security-constraint>

If you’ve followed these instructions and the one on the blog-post Securing a Web Application on Glassfish using JAAS, you should now be able to authenticate different users with different roles in your app using the File-Realm.

In the next articles of the series, we will look how to create an own realm, how to replace the form-based login with a JSF-Based one and how to work with roles in your JSF-Pages.

References:

• Authentication in JSF2 with JAAS: Part 1 – Understand the terminology
• Java Authentication and Authorization Service (JAAS)in Java 2, Standard Edition (J2SE) 1.4
• Securing a Web Application on Glassfish using JAAS
• Structure of sun-web.xml file

In this first part of the series, I’ll try to cover the terminology used in easy to understand words.

These are the terms, you’ll need to know:

• realm: A realm is basically a "user database", being it a flat file with user/pass + group info, database tables or even an ldap directory or something else you can imagine, like facebook connect or google authentication system. It may be used by n applications.
• user: A user is a person or program wishing to authenticate against our server/app. If you only make your website for real persons, these are your users. If you also offer a webservice, other programs accessing that service are also users. A user belongs to a realm, so may be valid in n applications (see principal below)
• role: Roles are assigned to users and/or groups in an application. E.g. GUEST for a not authenticated visitor, LOGGEDIN_USER for an authenticated user, MODERATOR or ADMIN for special people.
• group: Groups are like roles, but they are used over multiple applications and mapped to specific ROLES on an per-application-basis
• principal: A Principal is an authenticated user in the scope of an application. The same user may have different principals in different applications. A principal is identified by its name and authenticated using authentication data (credentials)
• security policy domain: Also called security domain or realm. Basically, the database where you lookup users. But in this meaning, its where the realms are used, being it application1, application2, applicationN
• Security attributes: are attributes associated with every principal, like " is allowed to access the admin area" or stuff like that.
• credential: contains or references security attributes; are used to authenticate a Principal for a Java EE product service (your webapp)

If you want to get the original documentation, take a look at the Security chapter in the Java EE 6 Tutorial Volume I

Further references, which I’ll probably be using in the next posts of these series:

• JSR 115: JavaTM Authorization Contract for Containers
• Java Authentication and Authorization Service (JAAS)in Java 2, Standard Edition (J2SE) 1.4
• JavaTM Authentication and Authorization Service (JAAS) Reference Guide
• JavaTM Authentication and Authorization Service (JAAS) LoginModule Developer’s Guide
]]> http://dominikdorn.com/2010/02/jaas-authentication-jsf2-terminology/feed/ 2 http://dominikdorn.com/2010/02/quercus-glassfish-v3-java_bean/ http://dominikdorn.com/2010/02/quercus-glassfish-v3-java_bean/#comments Thu, 04 Feb 2010 22:50:59 +0000 Dominik Dorn http://dominikdorn.com/?p=175 Current Quercus java_bean() method does not work in Glassfish v3, because Caucho are cooking their own soup with everything new of JavaEE6 (I don’t understand why they need to reinvent all of JavaEE6 like JSF, CDI, etc. for their own app-server… why don’t use something existing and build on top of it? Why don’t push your own projects further, like Quercus, Hessian, Burlap and co.? )

If you, like me, want to use managed beans from inside your php code, and find out, that jndi_lookup and java_bean() do not work (= return null every time), try this little method

1 2 3 4 5 6 7 8 9 10

function my_java_bean($name) { $beanManager = quercus_get_servlet_context()->getAttribute("javax.enterprise.inject.spi.BeanManager"); $beans = $beanManager->getBeans($name); if($beans == null || count($beans) < 1) return null; $object = $beanManager->getReference($beans[0], $beans[0]->getClass(), $beanManager->createCreationalContext($beans[0])); return $object; }

]]> http://dominikdorn.com/2010/02/quercus-glassfish-v3-java_bean/feed/ 0 http://dominikdorn.com/2009/12/fileupload-with-jsf-2-and-servlet-3-0/ http://dominikdorn.com/2009/12/fileupload-with-jsf-2-and-servlet-3-0/#comments Mon, 28 Dec 2009 23:11:28 +0000 Dominik Dorn http://dominikdorn.com/?p=169 As I had serious problems with FileUpload and the existing “solutions”, mainly Tomahawk, MyFaces, RichFaces, PrimeFaces, etc. which are all not 100% ready for JSF 2.

I created a taglib based on the code of BalusC.
You can find the Taglib on Github

The source code is based on these two posts:

1. Uploading files in Servlet 3.0
2. Uploading files with JSF 2.0 and Servlet 3.0

Simply check out the code with git

1	git clone http://github.com/domdorn/fileUploadServlet3JSF2.git

then install the taglib with

1	mvn clean compile install

and import it into your maven project like this

net.balusc
fileUploadServlet3JSF2
1.0-SNAPSHOT

You can then use the taglib in your Facelets files like this:

Upload.xhtml

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:hh="http://balusc.net/jsf/html" > <h:head> <title>FileUploadTest</title> </h:head> <body>   <h:form prependId="false">   <h:messages globalOnly="false" id="messages"/>   <h:panelGrid columns="3">   <label for="someText"> SomeText: </label>   <h:inputText id="someText" value="#{uploadBean.someText}" required="true"> <f:ajax event="blur" render="someText someTextMessage" execute="@this"/> </h:inputText> <h:message for="someText" id="someTextMessage"/>   <label for="filenameText"> Filename: </label>   <h:inputText id="filenameText" value="#{uploadBean.filename}" required="true"> <f:ajax event="blur" render="filenameText filenameTextMessage" execute="@this" /> </h:inputText> <h:message for="filenameText" id="filenameTextMessage"/> </h:panelGrid> </h:form>   <h:form enctype="multipart/form-data" prependId="false"> <h:panelGrid columns="3"> <h:outputLabel for="uploadedFile" rendered="#{empty uploadBean.file}"> Input File: </h:outputLabel> <hh:inputFile id="uploadedFile" value="#{uploadBean.file}" rendered="#{empty uploadBean.file}"> <f:validator validatorId="fileValidator"/> </hh:inputFile> <h:message for="uploadedFile"/> </h:panelGrid> <h:commandButton value="submit" action="#{uploadBean.submit}" /> </h:form> </body> </html>

The bean:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

package com.dominikdorn.simpleFileUpload.beans;</code>   import javax.faces.bean.ManagedBean; import javax.faces.bean.RequestScoped; import javax.faces.bean.SessionScoped; import javax.faces.bean.ViewScoped; import java.io.File;   @ViewScoped @ManagedBean public class UploadBean {   private File file; private String filename;   public String getFilename() { return filename; }   public void setFilename(String filename) { System.out.println("binding filename"); this.filename = filename; }   public String submit() { System.out.println("calling submit");   if(file != null) { this.filename = file.getName(); }   System.out.println("processed"); // do what you want with the file return "yeah"; }   public UploadBean() { }   public File getFile() { return file; }   public void setFile(File file) { this.file = file; }   private String someText;   public String getSomeText() { return someText; }   public void setSomeText(String someText) { System.out.println("binding someText"); this.someText = someText; } }

]]> http://dominikdorn.com/2009/12/fileupload-with-jsf-2-and-servlet-3-0/feed/ 8 http://dominikdorn.com/2009/12/javaee-6-jsf-2-context-dependency-injection/ http://dominikdorn.com/2009/12/javaee-6-jsf-2-context-dependency-injection/#comments Fri, 18 Dec 2009 10:28:36 +0000 Dominik Dorn http://dominikdorn.com/?p=162 Andy Gibson has blogged about how to use Context & Dependency Injection ( CDI, the @Inject annotation ) with JSF 2.

Also take a look at the comments, there is some useful info there too!

]]> http://dominikdorn.com/2009/12/javaee-6-jsf-2-context-dependency-injection/feed/ 0 http://dominikdorn.com/2009/12/spring-3-0-is-final/ http://dominikdorn.com/2009/12/spring-3-0-is-final/#comments Wed, 16 Dec 2009 21:26:44 +0000 Dominik Dorn http://dominikdorn.com/?p=155 As Jurgen Hoeller posted today, Spring 3.0 is final!

I will check it out as soon as possible

 

]]> http://dominikdorn.com/2009/12/spring-3-0-is-final/feed/ 0 http://dominikdorn.com/2009/12/glassfish-v3-final-available/ http://dominikdorn.com/2009/12/glassfish-v3-final-available/#comments Thu, 10 Dec 2009 18:30:18 +0000 Dominik Dorn http://dominikdorn.com/?p=144 Paul Sterk just announced the availability of the final version of Glassfish v3!

I just tried it out and it really rocks! Download, extract, start domain, running!
Even PHP Applications are easily possible: I will look further into this this weekend!

]]> http://dominikdorn.com/2009/12/glassfish-v3-final-available/feed/ 0 http://dominikdorn.com/2009/11/trying-out-glassfish-v3/ http://dominikdorn.com/2009/11/trying-out-glassfish-v3/#comments Thu, 19 Nov 2009 21:48:37 +0000 Dominik Dorn http://dominikdorn.com/?p=127 If you, like me, like to try out Glassfish v3 with its build in support for JavaEE6 and JSF 2, don’t even try to use the Glassfish v3 Preview Edition available on the Glassfish website.
Instead, use one of the nightly builds
http://download.java.net/glassfish/v3/nightly/
You will save yourself a lot of headaches.
]]> http://dominikdorn.com/2009/11/trying-out-glassfish-v3/feed/ 0