Hi all,
We are just moving from version 3 of Ofbiz to what is currently in head... which means we can start helping out again... yeah baby. We use CAS (http://www.ja-sig.org/products/cas/) to do authentication on our system and have hacked up Ofbiz 3 to play nice. Anyhow what is exciting is I noticed in framework/security/config/security.properties on line 73 there is the following: # -- HTTP header based ID (for integrations; uncomment to enable) #security.login.http.header=REMOTE_USER which is then processed by framework/webapp/src/org/ofbiz/webapp/control/LoginWorker.java around line 611 on: ... // header field found; log the user in try { GenericValue userLogin = delegator.findOne("UserLogin", false, "userLoginId", headerValue); if (userLogin != null) { String enabled = userLogin.getString("enabled"); ... So the problem is the CAS Java client doesn't put anything in the http header... it populates the HttpServletRequest's getRemoteUser() method (http://www.ja-sig.org/wiki/display/CASC/Configuring+the+JA-SIG+CAS+Client+for+Java+in+the+web.xml ... bottom of page). When I got the user with getRemoteUser() in the LoginWorker.java file it worked beautifully... So I am wondering if anyone has any objections to adding a property to the security.properties file like: # -- HttpServletRequest getRemoteUser() based ID (for integrations; uncomment to enable) #security.login.http.servlet.getremoteuser.allow=true and in LoginWorker.java add some code to check property and suck in remote user from request if ok. Ideas, comments, feedback? Guy -- Guy Gershoni Conchus Email: [hidden email] Web: www.conchus.com |
Why don't you create a patch and submit it to Jira? Then we can take a
look at it and comment, etc. -Adrian Guy Gershoni wrote: > Hi all, > > We are just moving from version 3 of Ofbiz to what is currently in > head... which means we can start helping out again... yeah baby. > > We use CAS (http://www.ja-sig.org/products/cas/) to do authentication > on our system and have hacked up Ofbiz 3 to play nice. > > Anyhow what is exciting is I noticed in > framework/security/config/security.properties on line 73 there is the > following: > > # -- HTTP header based ID (for integrations; uncomment to enable) > #security.login.http.header=REMOTE_USER > > which is then processed by > framework/webapp/src/org/ofbiz/webapp/control/LoginWorker.java around > line 611 on: > > ... > // header field found; log the user in > try { > GenericValue userLogin = > delegator.findOne("UserLogin", false, "userLoginId", headerValue); > if (userLogin != null) { > String enabled = userLogin.getString("enabled"); > ... > > So the problem is the CAS Java client doesn't put anything in the http > header... it populates the HttpServletRequest's getRemoteUser() method > (http://www.ja-sig.org/wiki/display/CASC/Configuring+the+JA-SIG+CAS+Client+for+Java+in+the+web.xml > ... bottom of page). > > When I got the user with getRemoteUser() in the LoginWorker.java file > it worked beautifully... So I am wondering if anyone has any > objections to adding a property to the security.properties file like: > > # -- HttpServletRequest getRemoteUser() based ID (for integrations; > uncomment to enable) > #security.login.http.servlet.getremoteuser.allow=true > > and in LoginWorker.java add some code to check property and suck in > remote user from request if ok. > > Ideas, comments, feedback? > > Guy > > |
Hey Adrian,
Thanks for the speedy reply. Since you didn't scream in pain and horror at my proposal have decided to move forwards. Jira issue: https://issues.apache.org/jira/browse/OFBIZ-1906 Guy On Tue, Aug 5, 2008 at 10:55 AM, Adrian Crum <[hidden email]> wrote: > Why don't you create a patch and submit it to Jira? Then we can take a look > at it and comment, etc. > > -Adrian > > Guy Gershoni wrote: >> >> Hi all, >> >> We are just moving from version 3 of Ofbiz to what is currently in >> head... which means we can start helping out again... yeah baby. >> >> We use CAS (http://www.ja-sig.org/products/cas/) to do authentication >> on our system and have hacked up Ofbiz 3 to play nice. >> >> Anyhow what is exciting is I noticed in >> framework/security/config/security.properties on line 73 there is the >> following: >> >> # -- HTTP header based ID (for integrations; uncomment to enable) >> #security.login.http.header=REMOTE_USER >> >> which is then processed by >> framework/webapp/src/org/ofbiz/webapp/control/LoginWorker.java around >> line 611 on: >> >> ... >> // header field found; log the user in >> try { >> GenericValue userLogin = >> delegator.findOne("UserLogin", false, "userLoginId", headerValue); >> if (userLogin != null) { >> String enabled = >> userLogin.getString("enabled"); >> ... >> >> So the problem is the CAS Java client doesn't put anything in the http >> header... it populates the HttpServletRequest's getRemoteUser() method >> >> (http://www.ja-sig.org/wiki/display/CASC/Configuring+the+JA-SIG+CAS+Client+for+Java+in+the+web.xml >> ... bottom of page). >> >> When I got the user with getRemoteUser() in the LoginWorker.java file >> it worked beautifully... So I am wondering if anyone has any >> objections to adding a property to the security.properties file like: >> >> # -- HttpServletRequest getRemoteUser() based ID (for integrations; >> uncomment to enable) >> #security.login.http.servlet.getremoteuser.allow=true >> >> and in LoginWorker.java add some code to check property and suck in >> remote user from request if ok. >> >> Ideas, comments, feedback? >> >> Guy >> >> > -- Guy Gershoni Conchus Email: [hidden email] Web: www.conchus.com |
Free forum by Nabble | Edit this page |