All,
Sorry I didn't respond to the questions around the password validation and
the "change required at next logon" issues earlier, but I just was too busy
to be able to work through the mailing list.
Although several of the mentioned problems *can* already be solved (partly)
through the springframework configuration, I recognize this isn't very
transparent right now.
I've created new issue http://issues.apache.org/jira/browse/JS2-359 to solve
this and hope to complete this rather soon (within a week or so) and at least
before M4 is released.
If you think the solution I propose is still not covering your specific problem,
please comment on the issue and I'll try to accommodate for it if feasible.
Regards,
Ate
James Liao wrote:
Hi randy,
I've checked it.
There is no this issue(Password must be change at next logon on) for
the j2 bundled ldap authentication provider, cause it still didn't
support this function yet. Sorry for the mess-up in my previous email.
The reason why I mess all these things up is that I implement all the
security handlers and dao which based on Default database based
authentication provider. But I do insist
that J2 should support configuration of "change required at next
logon", "enabled" and "expired"(maybe) for the default authentication
provider.
- James Liao
On 9/2/05, James Liao <[EMAIL PROTECTED]> wrote:
Hi randy,
Thanks for your response and thanks for J2 dev team. I'll check it out
later! If it didn't change, I am thinking about fire a improvement
issue in Jira.
- James Liao
On 9/2/05, Randy Watler <[EMAIL PROTECTED]> wrote:
James,
I know the dev team is aware of this issue, that is why I think it has
been addressed in M4 to some degree: the admin servlet seems to have the
default unchecked now.
Please let me know if the M4 admin portlet is still forcing the users to
change their passwords. I cannot speak authoratively on the LDAP
integration behavior, sorry.
Randy
James Liao wrote:
Hi Randy,
One more thing, if I just config an exist ldap server as the only one
or one of the authentication providers. All the ldap users are forced
to change their password. Well, yes, as you mention below, the
administrator could change them in user detail portlet, but if there
are hundreds of ldap users, then it is unacceptable.
Hope I'm wrong, cause I just test that in j2-m3.
- James Liao
On 9/1/05, James Liao <[EMAIL PROTECTED]> wrote:
Hi randy,
Thanks for responseding!
I think what we need is when we create a new user, the "change
required at next logon" check box could be config if it is checked or
not. Now the default is checked. There is no way to config it.
- James Liao
On 9/1/05, Randy Watler <[EMAIL PROTECTED]> wrote:
Guys,
I am not totally sure, but it appears that it is no longer the default
for new users to be required to change their passwords in M4/svn HEAD...
in any case, there is a checkbox option under the password tab that
allows the admin to choose the policy per account.
I do recall some issue with the hsqldb and password expiration... is
that possibly the issue here?
Randy
James Liao wrote:
Well, I just rewrite a method named getPasswordCredential in class
DefaultCredentialHandler.
try {
//
// FIXME A bad way to ignore credential's
update required modification from ipcInterceptor_.afterLoad()
// J2 should let portal administrator to
determine if a user first time log into portal must change
// their password immediately. This
function should be implement in
InternalPasswordCredentialStateHandlingInterceptor.afterLoad().
//
//
boolean hack =
credential.isUpdateRequired(); // Save the update required status.
if ( ipcInterceptor_ != null &&
ipcInterceptor_.afterLoad(pcProvider_, username, credential) ) {
//
// update InternalUserPrincipal to
save post processed data
//
credential.setUpdateRequired(hack); //
Set it back to ignore the change in above afterLoad method.
securityAccess_.setInternalUserPrincipal(internalUser,internalUser.isMappingOnly());
}
break;
} catch (SecurityException e) {
LOG.error(ResourceBundleUtils.getString(BUNDLE,
"BwLdapCredentialHandler.FailToLoadCredential", credential), e); //
NOI18N
}
I do think it is not a good solution for this problem, I hope j2 team
could provide this functionality,
- James Liao
On 9/1/05, James Dixon <[EMAIL PROTECTED]> wrote:
Thanks James
I've had a bit of a look at that DefaultCredentialHandler. I haven't had
to plumb the depths of the Jetspeed Source Code too much yet, and so it was
fairly unfamiliar to me - could you provide some more details of the hack ?
Cheers
James
-----Original Message-----
From: James Liao [mailto:[EMAIL PROTECTED]
Sent: Thursday, 1 September 2005 10:57 AM
To: Jetspeed Users List
Subject: Re: Turn off 'change required at next logon' - an easy one??
Hi james,
I am also interested in this. But it seems that there is no way to turn it
off in spring configuration file. So I just hack it in class:
DefaultCredentialHandler.
regards,
-James Liao
On 9/1/05, James Dixon <[EMAIL PROTECTED]> wrote:
An easy one, I hope.
The default setting when you create a new user through the jetspeed
administrative portlet is for the user to change their password at
next login. As we will be importing existing passwords, we will not
want to do that. Can I turn off this setting so that users do not
have to change their password the first time they log in? If so,
where is the parameter found? - I couldn't see it in security-spi-atn.xml.
Thanks
James
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
