Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JSF, spring security integration, inject dataSource jdbc  RSS feed

 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm integrating spring security to my JSF. However I don't know how to do to get the DataSource. In the spring security documentation it's done like this :


The example below assumes that you have already defined a DataSource within your application.



Now this is when using the spring framework and mvc. However I'm using JSF and spring security is only used for security.
I don't know how to set up the datasource.



How should I define and inject the datasource ?

On stack overflow they advised me to do this :

use @Configuration class that provides a datasource through @Bean


but this is really vague. So I added this to my web.xml:


and made an application-context.xml:



But I'm getting no bean definition found for DataSource.

Thanks in advance. I really don't find much on google.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You assigned the Datasource an ID value of "Datasource". That violates the convention that object instance names should begin with a lower-case letter. It therefore defeats Spring's auto-wiring because auto-wiring defaults to looking for the class name folded to an initial lowercase per the convention.

To inject a Datasource directly into JSF code, configure the Spring-JSF bridge into faces-config.xml and inject it as a ManagedProperty (not Autowired). But I don't recommend that. I recommend backing off a layer and making a separate (Spring) bean to hold the persistence functions and autowired Datasource, then injecting THAT bean as a ManagedProperty into the JSF Managed Bean.

Aside from general tidiness/separation of concerns/reusability/testing advantages, the separate persistence services bean can be Spring annotated with the @Repository and @Transaction annotations and the like. A bean instantiated by JSF (ManagedBean) instead of by the Spring Bean Factory isn't going to honor those annotations.
 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your answer. I'm not really familiar with the spring framework as you can tell. I've a userService implementation where I use an EntityManager to find users in the database. Can't I use that for spring security to find users instead of injecting the dataSource ?

You assigned the Datasource an ID value of "Datasource". That violates the convention that object instance names should begin with a lower-case letter. It therefore defeats Spring's auto-wiring because auto-wiring defaults to looking for the class name folded to an initial lowercase per the convention.


So aside from the uppercase "d" I should keep my xml file the way it is ? I still have the error :



To inject a Datasource directly into JSF code, configure the Spring-JSF bridge into faces-config.xml and inject it as a ManagedProperty (not Autowired). But I don't recommend that. I recommend backing off a layer and making a separate (Spring) bean to hold the persistence functions and autowired Datasource, then injecting THAT bean as a ManagedProperty into the JSF Managed Bean.


The class where I inject my datasource is not a managed bean, so I'm not you where you meant to say I should inject the datasource in my jsf code. It is like this:

@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {



Thanks
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mostly I find the JEE standard container security sufficient, so I only have 1 or 2 apps that use Spring security and thus I'm not up to date on all its ins and outs. But I think I can suggest a couple of things.

Firstly, a DataSource is usually injected externally into webapps, not configured as part of the webapp itself. In Tomcat, for example, you'd define a database Connection Pool either in the app's Context definition (server-specific deployment descriptor) or - if the pool is intended to be shared between multiple webapps, by defining it in Tomcat's server.xml config file. Servers such as IBM WebSphere or Oracle WebLogic provide an admin GUI function for that, JBoss/Wildfly has its own special config files.

To make this Datasource available as a Spring bean, it can be very easy:


Where "jdbc/localDB is the JNDI name that was assigned as part of the pool definition.

Your sample config bean injects (via Autowire) the DataSource, but it doesn't appear to use it - you defined an "in memory authentication" configuration, and that suggests that it's probably not going to be checking in with the database. But I'd have to read up on the Spring security docs to be sure.

The comment I made about injecting datasources directly into JSF code was in relation to people who attempt to make their GUI model beans (backing beans) be "all-in-one" beans with their own persistence logic in them. It's unrelated to what you're doing with the Spring security.
 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:Mostly I find the JEE standard container security sufficient, so I only have 1 or 2 apps that use Spring security and thus I'm not up to date on all its ins and outs. But I think I can suggest a couple of things.


So you are saying Java ee standard container security is sufficient. Isn't that vanilla security system less safe ? Like CSRF vulnerabilities and so on. I don't know much about security and I'm not trying to build a bank website but I'd still like my future users if any to have their passwords protected. I've been advised to use a framework to have less work. Since I'm trying to do so I've gone absolutely nowhere and I'm really frustrated. So if the vanilla security system is good enough I'll just go for it even though I gave up already 20 days ago. As you can see in this topic here http://www.coderanch.com/t/649434/Web-Services/java/login-form-authentification-Security-realms. Anyway I'll try my luck a second time.

Edit: I did it. Took me an hour to set up and now it's working. Fuck those frameworks really. I don't know why I struggled with the vanilla securisation, maybe it's coming with a clear mind that changed things..

Tim Holloway wrote:
Firstly, a DataSource is usually injected externally into webapps, not configured as part of the webapp itself. In Tomcat, for example, you'd define a database Connection Pool either in the app's Context definition (server-specific deployment descriptor) or - if the pool is intended to be shared between multiple webapps, by defining it in Tomcat's server.xml config file. Servers such as IBM WebSphere or Oracle WebLogic provide an admin GUI function for that, JBoss/Wildfly has its own special config files.

Yeah it's already defined in my server.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you mostly cancelled out your last questions, but as regards the safety of the J2EE standard security framework, no, it does not address externalities such as CSRF. It's primarily there to provide a solid block against unauthorized access to secured URLs, to supply the authenticated user's identity on request, and to provide an API that allows code to allow or disallow user services to be performed for a URL request. For full-stack JEE servers, the authorization control also configures into components such as EJBs.

That's a pretty solid foundation, since, as I said, you cannot exploit code that you cannot get to, and the server will bounce you long before any application code shows if you request an unauthorized URL. But it's only a start and can be augmented as needed.

The stock security framework will definitely protect passwords, since the passwords are not processed by the application, they're processed by the server Realm. So, for example, authenticating against an SQL database causes the server to issue a request such as this:


Note that count returned is 0 if the password doesn't match and the login should be rejected. Note also that the database NEVER sends passwords to the webapp server when you issue this request, so the webapp server doesn't have anything returning that a casual vandal could exploit.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!