Reposted from http://d.hatena.ne.jp/ssogabe/20090611/1244735348#c
A Japanese Hudson developer (Seiji Sogabe) reports that the access to a Hudson where the anonymous user don't have the
read access results in a failure to retrieve data, even when the credential is given.
My hypothesis is that he's using "delegate to servlet container" security realm, which would require the login
credential to be sent to /j_security_check (as defined by the servlet spec) as opposed to /j_acegi_security_check (as
used by Acegi on all the other authentication realms.)
If there's something Hudson can do to simplify the process of programmatic login (like exposing the login URL
somewhere?), I'd be happy to do so.
Currently the servlet container security realm is not supported by NetBeans. (Could be if there is sufficient interest.)
But based on the dialog shown, it looks to me like he is using an Acegi-based security realm. Not sure, will have to try
I'm requesting the original reporter to clarify the set up, so hopefully he'll be able to save you some effort.
Well, I've met this issue last week, and I can provide some information as well on how to set up an environment to test
We need a Glassfish 2.1, a hudson.war (1.311), a crafted web.xml and NetBeans 6.7
1. unzip hudson.war to into a separate folder
2. overwrite the web.xml in the WEB-INF/ folder in that separate folder
3. create and start a fresh Glassfish domain
4. Open its admin console in a browser
5. At Configuration > Security enable the "Default Principal to Role Mapping"
6. At Configuration > Security > Realm > file set "Assign Group" to "hudson", then press save
7. Press manage Users and add the following users:
7.1 test_user/12345678 with group "admin"
7.2 dummy/dummy with no group assignment
8. Optional: Set the log level of the Web Container to WARNING at Application Server > Logging > Log Levels
9. At Applications > Web Applications deploy hudson from the separate folder
10. Launch hudson
11. At Manage Hudson > Configure System set the Enable Security
12. Select "Delegate to servlet container" with "Project-based Matrix Authorization Strategy"
13. Add group "admin" and grant all possible roles.
14. Add user "authenticated" and grant read rights. Leave the Anonymous user as it is.
15. Save the configuration
16. Log on as test_user to hudson
17. Create a Job "Test"
18. See how it works with NetBeans...
Created attachment 83896 [details]
The crafted web.xml
Thank you Leslie for the detailed instructions! I can reproduce and will see if I can fix.
*** Issue 166755 has been marked as a duplicate of this issue. ***
I think fixed in cdev #02bb30063656. NB should now be able to authenticate:
- Hudson instances using container-based authentication (formerly only supported Acegi)
- instances for which the anonymous user does not even have read access
I would certainly appreciate testing of authentication in dev builds once this fix becomes available (a note will be
posted here automatically when that happens).
Integrated into 'main-golden', will be available in build *200906231401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <email@example.com>
Log: #167432: authentication fixed to handle container-based auth, and no perms for anon.
Works nicely on the dev builds.
The fix has been ported into the release67_fixes repository.
*** Issue 168240 has been marked as a duplicate of this issue. ***