Hi All,
I've stumbled across some rather interesting behaviour which I'd like to
know if someone else can replicate, and, if this is expected with my setup.
I'm running JSPWiki v2.10.2-svn-38 with container-managed
authentication, with user accounts provisioned using a file-based
security realm in Payara Server 4.1. My JSPWiki policy file has been
deliberately locked down such that only authenticated users can view
content.
The userdatabase.xml file contains the following only, as one would expect:
<?xml version="1.0" encoding="UTF-8"?>
<users>
<user uid="625526c4-blahblahblah" loginName="admin"
wikiName="Administrator" fullName="Administrator" email=""
password="{SSHA}somepassword" created="2016.02.20 at 23:11:59:610 NZDT"
lastModified="2016.02.20 at 23:11:59:610 NZDT" lockExpiry="" >
</user>
</users>
To test the installation is secure a user performs the following:
1. Navigate to the JSPWiki login screen
2. Click on ["Don't have account?"] "Join JSPWiki now!
3. On the "Register a new user!" page, enter a random Name and email
address, and click "Create a new user profile". The account cannot
be created.
Now, leaving this browser tab as-is, open a second browser tab.
Authenticate to JSPWiki as an authorised user. Next, switch back to the
original tab. Repeat step 3 above. The session logs you in. Under "User
Preferences -> Profile" for the logged-in user, the "Name" and "Email
address" values have changed to what was set in step 3 above. The "Login
name" however is still the account derived from the Payara security realm.
Now, if one inspects the userdatabase.xml file, a new entry *has* been
created. In the following example "derekz" is set in the file-based
security realm, whereas "Alex" is the name set when registering the new
user account directly:
<user uid="b561f8e2-blahblahblah" loginName="derekz" wikiName="Alex"
fullName="Alex" email="a...@example.com" password="" created="2016.02.2
0 at 23:28:59:268 NZDT" lastModified="2016.02.20 at 23:28:59:268 NZDT"
lockExpiry="" >
</user>
</users>
So what gives? Something tells me this perhaps shouldn't be working
quite like this, even with the unlikely scenario of attempting to
register a new user when the same authorised user is already authenticated.
Cheers,
Dave
--
Dave Koelmeyer
http://blog.davekoelmeyer.co.nz
GPG Key ID: 0x238BFF87
