Hi Eric,
thanks and I will do at a later point in time. For now your fixes
regarding the useradmin group where all I needed.

Regards,
 Markus

On Thu, May 19, 2011 at 7:31 AM, Eric Norman <[email protected]> wrote:
> Hi Markus,
>
> I just added some services for usermanager and accessmanager that mirror the
> functionality of the REST operations to resolve SLING-2083 and SLING-1555.
>
> Please try it out when you get a chance to verify that it is sufficient to
> solve your use case.
>
> Regards,
> Eric
>
> On Sat, May 7, 2011 at 11:29 AM, Eric Norman <[email protected]>wrote:
>
>> Hi Markus,
>>
>> Yes, that is a good point.  I was reviewing the open issues and it looks
>> like we already have an issue 
>> (SLING-1555<https://issues.apache.org/jira/browse/SLING-1555>)
>> requesting OSGi services for the user management actions.
>>
>> Of course, patches are welcome to add this functionality.  If no one else
>> gets to it, I can take a look when I get some free time.
>>
>> Regards,
>> Eric
>>
>> On Sun, May 1, 2011 at 11:56 PM, Markus Joschko 
>> <[email protected]>wrote:
>>
>>> Hi Eric,
>>>
>>> this sounds great but is already quite specific and has to deal with
>>> quite some configuration.
>>> (mailserver configuration, mail templates (maybe localized etc))
>>>
>>> I think it would be sufficient to extract a password service which is
>>> available in the osgi environment
>>> and allows other components to request a pw change.
>>>
>>> The applications are then free to build their own PW reset workflow
>>> while the configuration for the PW reset (digest etc)
>>> is still kept in one place.
>>>
>>> WDYT?
>>>
>>> Regards,
>>>  Markus
>>>
>>> On Sat, Apr 30, 2011 at 9:05 PM, Eric Norman <[email protected]>
>>> wrote:
>>> > Hi Markus,
>>> >
>>> > Yes, you are right, the existing usermgmt bundle doesn't handle that use
>>> > case.
>>> >
>>> > We could probably add that feature to the usermgmt bundle with a patch
>>> and a
>>> > new release of the usermgmt bundle.
>>> >
>>> > To reset the password in a secure way, I am thinking of something like
>>> this:
>>> >
>>> >   1. A new RequestResetPwd servlet generates some random reset pwd token
>>> >   (that expires after n days) when invoked.  Then it sends an email to
>>> the
>>> >   user with a link containing the token.
>>> >   2. The target user gets the reset pwd email and clicks the link
>>> contained
>>> >   in it.
>>> >   3. A sling script handles the link request, validates the reset pwd
>>> token
>>> >   and, if valid, displays a form where the user can enter a new
>>> password.
>>> >   4. A POST from the form in #3 targets a new ResetPwdWithToken servlet
>>> >   that validates the reset pwd token again and then assigns the new
>>> password
>>> >   and removes the reset pwd token so it can not be used again.
>>> >
>>> > Does that look ok?
>>> >
>>> > Regards,
>>> > Eric
>>> >
>>> > On Sat, Apr 30, 2011 at 6:46 AM, Markus Joschko <
>>> [email protected]>wrote:
>>> >
>>> >> Hi,
>>> >> I am currently developing an UI for the sling usermgmt and found that
>>> >> I can't realize a common use case:
>>> >> - PW reset (manually by admin or automatically by user)
>>> >>
>>> >> The old PW is always required but in the given use case it is most
>>> >> likely that the PW is no longer available.
>>> >> I would implement this on my own but the only two ways I see seem to
>>> >> be suboptimal:
>>> >> 1) Create a new overwritePW which accepts only requests from admins.
>>> >> However as I can not extend AbstractUserPostServlet
>>> >>   from my code, I have no access to the digestPassword method and
>>> >> would have to copy code and even worse make sure, that the digest
>>> >> algorithm
>>> >>   is then always configured the same on the create user? servlet and
>>> >> the overwritePW servlet which is suboptimal.
>>> >> 2) Create a filter to provide the oldPW automatically to the changePW
>>> >> servlet in case an admin overwrites a PW.
>>> >>    That won't work with the CryptedSimpleCredentials I guess.
>>> >>
>>> >> So I am stuck. How to realize PW reset?
>>> >>
>>> >> Thanks,
>>> >>  Markus
>>> >>
>>> >
>>>
>>
>>
>

Reply via email to