Re: Tokens

[Francesco Chicchiriccò <il...@apache.org>]

On 31/05/2012 20:55, Bob Lannoy wrote:
> On May 31, 2012 4:41 PM, "Francesco Chicchiriccò" <il...@apache.org>
> wrote:
>> Hi Bob,
>> I've finally had chance to take a closer look at your requirements and
>> was able to spend some time looking at how such requirements could be
>> implemented in Syncope with as less modifications as possible.
> It seems that I went a bit wild on the modification side of things ;)
> I have still some remarks/questions.
>
>> I've just fixed (you have to wait for Jenkis to deploy new artifacts)
>> our standard UserController.activate() in order to be effective; here it
>> goes the (fixed) flow:
>>
>> 1. UserController.activate() is called via REST: just be sure to call
>> this method with an UserTO object where you actually put the token as
>> provided by the user (UserTO.setToken()).
> Ok this is what I needed, I'll change my frontend.
> I find it somewhat strange to pass a userTO just for the userid and the
> token. Wouldn't a simpler activate method make more sense e.g.
> activate/{userid}?token=...? This is similar to the link the user gets. Or
> is this against rest-principles?

Not at all, at least as far as I know :)
Anyway, I've opened SYNCOPE-91 for taking care of this suggestion of
yours (and more).

>> in your workflow XML. SyncopeUser.checkToken() will check if the token
>> is correct and still valid.
> As I explained in a previous post it makes sense to add a method to
> SyncopeUser that only checks for an expired token, e.g. hasTokenExpired().
> The workflow could then handle a wrong token and expired token as two
> different flows. I want to delete the user with an expired token. But I'm
> unable to, could you give an idea how this should be done in the Delete
> class of the workflow?

If you take a look at ActivitiUserWorkflowAdapter.delete() (this is
called by UserController.delete()):

        doExecuteTask(user, "delete", null);
        userDAO.delete(user);

This means that first the "delete" task is executed (possibly involving
the Delete class, if workflow XML says so), then user is effectively
deleted.
Unfortunately, I don't think that userDAO.delete() can be called by the
Delete class because it would be in a non-transactional scope; anyway,
you can give it a try.
Alternatively, you can think to put users to be deleted in a "sink"
status and to create a SchedTask for periodically cleaning up such
sinked users.

>> There is also a generic UserController.executeWorkflow() taking UserTO
>> and task name as parameters for this purpose.
> Ok this might be handy for my password reset flow. To be sure, an example
> from the default workflow:
> when the user is in "active" there are currently three paths. If I would
> want to push the user to the suspend state I call the executeworkflow with
> the userTO and "suspend" as taskId?

Correct in principle, but consider that suspend() and reactivate() have
their own methods. Such methods (alongside with activate()) will take
care of forwarding the given action to underlying workflow + propagating
the new user status to associated external resources, if requested /
necessary.

Regards.

-- 
Francesco Chicchiriccò

ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/

Re: Tokens

[Bob Lannoy <bo...@gmail.com>]

Hi Francesco,

> Not at all, at least as far as I know :)
> Anyway, I've opened SYNCOPE-91 for taking care of this suggestion of
> yours (and more).

OK great.


> If you take a look at ActivitiUserWorkflowAdapter.delete() (this is
> called by UserController.delete()):
>
>        doExecuteTask(user, "delete", null);
>        userDAO.delete(user);
>
> This means that first the "delete" task is executed (possibly involving
> the Delete class, if workflow XML says so), then user is effectively
> deleted.
> Unfortunately, I don't think that userDAO.delete() can be called by the
> Delete class because it would be in a non-transactional scope; anyway,
> you can give it a try.
I tried that and it runs through the workflow activate -> activateGW
-> delete. I get strange error messages that the object has indeed
been deleted but it's still in the database and visible in console in
the "activate" state. I'll have to look into more detail.

> Alternatively, you can think to put users to be deleted in a "sink"
> status and to create a SchedTask for periodically cleaning up such
> sinked users.
OK maybe I'll try that.

>>> There is also a generic UserController.executeWorkflow() taking UserTO
>>> and task name as parameters for this purpose.
>> Ok this might be handy for my password reset flow. To be sure, an example
>> from the default workflow:
>> when the user is in "active" there are currently three paths. If I would
>> want to push the user to the suspend state I call the executeworkflow with
>> the userTO and "suspend" as taskId?
>
> Correct in principle, but consider that suspend() and reactivate() have
> their own methods. Such methods (alongside with activate()) will take
> care of forwarding the given action to underlying workflow + propagating
> the new user status to associated external resources, if requested /
> necessary.
I was only using them as an example. I was planning to use it for my
password reset functionality which also sends a token and sets a flag
on the user.
The front-end will handle the logic of activating & updating the password

In that case my workflow bit looks like
 <userTask id="active" name="Active"/>

    <sequenceFlow id="flow7" sourceRef="active" targetRef="activeGw"/>

    <exclusiveGateway id="activeGw"/>
    ...
    <sequenceFlow id="active2PasswordReset" sourceRef="activeGw"
targetRef="passwordreset">
      <conditionExpression xsi:type="tFormalExpression">${task ==
'passwordreset'}</conditionExpression>
    </sequenceFlow>
...
    <!-- will generate token and redirect to activate -->
    <serviceTask id="passwordreset" name="Generate token"
activiti:class="org.apache.syncope.core.workflow.activiti.GenerateToken"/>
    <sequenceFlow id="PWRflow1" sourceRef="passwordreset"
targetRef="activatePW"/>
...

So I need to call executeworkflow with the userTO and "passwordreset" as taskId?


The alternative is of course to add the passwordreset method in the
controller and handling in workflow, but that's on the roadmap ;)

best regards

Bob