[jira] [Commented] (SYNCOPE-1302) New expression model in mapping for internal attributes to access user relationships

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437215#comment-16437215
 ] 

ASF subversion and git services commented on SYNCOPE-1302:
--

Commit cb2c018b0028b2e4e9152ecbf1200196dc587d49 in syncope's branch 
refs/heads/2_0_X from [~skylark17]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=cb2c018 ]

[SYNCOPE-1302] Fix to handle multiple attribute values


> New expression model in mapping for internal attributes to access user 
> relationships
> 
>
> Key: SYNCOPE-1302
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1302
> Project: Syncope
>  Issue Type: Improvement
>  Components: console, core
>Reporter: Matteo Alessandroni
>Assignee: Matteo Alessandroni
>Priority: Minor
> Fix For: 2.0.9, 2.1.0
>
>
> It would be:
> {{relationships[relationshipType][relationshipAnyType].schema}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SYNCOPE-1301) Token creation is not threadsafe

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437160#comment-16437160
 ] 

ASF GitHub Bot commented on SYNCOPE-1301:
-

Github user IsurangaPerera closed the pull request at:

https://github.com/apache/syncope/pull/70


> Token creation is not threadsafe
> 
>
> Key: SYNCOPE-1301
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1301
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.0.8
>Reporter: Isuranga Perera
>Assignee: Francesco Chicchiriccò
>Priority: Major
> Fix For: 2.0.9, 2.1.0
>
>
> Token create method in AccessTokenDataBinderImpl[1] is not thread safe. This 
> could result in several problems including
>  * Exist 2 different access token for a particular user at a given time which 
> may result in an exception thrown by method call[2] since it expects a single 
> token a given user.
> In addition to that token replace is implemented as a combination of 2 
> different functionalities. Since the method is not thread safe this may cause 
> some unexpected behaviors (since there can be 2 tokens exist for a particular 
> user. same scenario as above).
> [1] 
> [https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/data/AccessTokenDataBinderImpl.java#L104]
> [2] 
> [https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/data/AccessTokenDataBinderImpl.java#L113]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] syncope pull request #70: [SYNCOPE-1301] fixed

[IsurangaPerera]

Github user IsurangaPerera closed the pull request at:

https://github.com/apache/syncope/pull/70


---

[jira] [Commented] (SYNCOPE-1299) Manual reconciliation

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437092#comment-16437092
 ] 

ASF subversion and git services commented on SYNCOPE-1299:
--

Commit 44a5e1da7adf8aa6519fea8410b82ea0ac6b425e in syncope's branch 
refs/heads/master from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=44a5e1d ]

[SYNCOPE-1299] Reworking REST service definition to allow more flexibility


> Manual reconciliation
> -
>
> Key: SYNCOPE-1299
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1299
> Project: Syncope
>  Issue Type: Improvement
>  Components: console, core
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
>Priority: Major
> Fix For: 2.0.9, 2.1.0
>
>
> Provide the feature - in Admin Console from either an User / Group / Any 
> Object and from an External Resource (under Topology) - which, given a User / 
> Group / Any Object and an External Resource, allows to force pushing or 
> pulling values for mapped attributes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SYNCOPE-1299) Manual reconciliation

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437091#comment-16437091
 ] 

ASF subversion and git services commented on SYNCOPE-1299:
--

Commit a07f3b948c34222d98509d1f11b20f054b392b02 in syncope's branch 
refs/heads/2_0_X from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=a07f3b9 ]

[SYNCOPE-1299] Reworking REST service definition to allow more flexibility


> Manual reconciliation
> -
>
> Key: SYNCOPE-1299
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1299
> Project: Syncope
>  Issue Type: Improvement
>  Components: console, core
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
>Priority: Major
> Fix For: 2.0.9, 2.1.0
>
>
> Provide the feature - in Admin Console from either an User / Group / Any 
> Object and from an External Resource (under Topology) - which, given a User / 
> Group / Any Object and an External Resource, allows to force pushing or 
> pulling values for mapped attributes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SYNCOPE-1301) Token creation is not threadsafe

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò reassigned SYNCOPE-1301:
---

Assignee: Francesco Chicchiriccò

> Token creation is not threadsafe
> 
>
> Key: SYNCOPE-1301
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1301
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.0.8
>Reporter: Isuranga Perera
>Assignee: Francesco Chicchiriccò
>Priority: Major
> Fix For: 2.0.9, 2.1.0
>
>
> Token create method in AccessTokenDataBinderImpl[1] is not thread safe. This 
> could result in several problems including
>  * Exist 2 different access token for a particular user at a given time which 
> may result in an exception thrown by method call[2] since it expects a single 
> token a given user.
> In addition to that token replace is implemented as a combination of 2 
> different functionalities. Since the method is not thread safe this may cause 
> some unexpected behaviors (since there can be 2 tokens exist for a particular 
> user. same scenario as above).
> [1] 
> [https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/data/AccessTokenDataBinderImpl.java#L104]
> [2] 
> [https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/data/AccessTokenDataBinderImpl.java#L113]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SYNCOPE-1301) Token creation is not threadsafe

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò resolved SYNCOPE-1301.
-
Resolution: Fixed

> Token creation is not threadsafe
> 
>
> Key: SYNCOPE-1301
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1301
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.0.8
>Reporter: Isuranga Perera
>Assignee: Francesco Chicchiriccò
>Priority: Major
> Fix For: 2.0.9, 2.1.0
>
>
> Token create method in AccessTokenDataBinderImpl[1] is not thread safe. This 
> could result in several problems including
>  * Exist 2 different access token for a particular user at a given time which 
> may result in an exception thrown by method call[2] since it expects a single 
> token a given user.
> In addition to that token replace is implemented as a combination of 2 
> different functionalities. Since the method is not thread safe this may cause 
> some unexpected behaviors (since there can be 2 tokens exist for a particular 
> user. same scenario as above).
> [1] 
> [https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/data/AccessTokenDataBinderImpl.java#L104]
> [2] 
> [https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/data/AccessTokenDataBinderImpl.java#L113]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Token creation is not thread safe

[Francesco Chicchiriccò]

On 13/04/2018 09:48, Isuranga Perera wrote:

Hi Francesco,

Yes, that will fix the problem.


Glad we agree :-)
I'll set SYNCOPE-1301; please close the PR #70.

Regards.


On Fri, Apr 13, 2018 at 1:00 PM, Francesco Chicchiriccò 
wrote:

On 09/04/2018 11:24, Isuranga Perera wrote:

Sure will work on that. Shall I create a JIRA?

Yes, please.

Do set both 2.0.9 and 2.1.0 as fix-for-versions since I will apply your
PR
both to branches master and 2_0_X.

Sorry for the delay will submit the ICLA asap
Ok, thanks.


Regards.

On Mon, Apr 9, 2018 at 2:45 PM, Francesco Chicchiriccò <


ilgro...@apache.org>
wrote:

On 09/04/2018 11:10, Isuranga Perera wrote:


Since such condition can happen only if the same user tries to login
from


2
mediums at the same, this is rarely happen. However that slight chance
may
prevent that particular user from login to the system until all or
all-1
access tokens are expired.
Using the UNIQUE constraint will definitely will provide a better
security
and furthermore will make the model more meaningful. On the other hand
this
will break the token replacing functionality since it first create a
token
(at this time there are 2 tokens in the db) and delete the last one.

What I propose is writing a separate query to replace tokens instead
of
using save & delete queries separately and furthermore we can use a
new
query to save tokens without affecting the UNIQUE constraints so that
no
need to mess with threading & @Transactional properties.

If you can come up with a proposal which works with all the supported


DBMSes, then please go on.

As already asked as comment in your recent PR: did you submit an ICLA
for
your contributions? Thanks.

Regards.

On Mon, Apr 9, 2018 at 2:06 PM, Francesco Chicchiriccò <

ilgro...@apache.org>

wrote:

On 09/04/2018 10:14, Isuranga Perera wrote:

The Read Committed isolation level ensures that data can only be read

by

a

transaction if it is in the committed state. It doesn't completely
isolate
this transaction(create) hence some other transaction can still use
this
method which results in the behavior I explained previously. Ideally
If
we're gonna use @Transactional annotation the isolation level should
be
serialized for create operation. Please correct me If I'm wrong.

I see your point - while I don't completely agree about the
likelihood

of

such race condition to actually happen.

At worse, you might end up in having two distinct JWT (Access Tokens)
values for a single user, which will anyway be subject to expiration
due
to

https://github.com/apache/syncope/blob/master/core/provision
ing-java/src/main/java/org/apache/syncope/core/provisioni
ng/java/job/ExpiredAccessTokenCleanup.java

For additional security, we might want to impose a UNIQUE constraint
on

https://github.com/apache/syncope/blob/master/core/persisten
ce-jpa/src/main/java/org/apache/syncope/core/persistenc
e/jpa/entity/JPAAccessToken.java#L48

(not sure to remember why the column is currently set as nullable,
though).
With UNIQUE owner, the step (5) in your sequence below will fail
anyway.

Again, given the chances that the race condition applies, and
considering
what would be the harm (nearly none, to me), I would rather avoid any
modification rather than imposing the UNIQUE constraint.


Regards.

On Mon, Apr 9, 2018 at 1:12 PM, Francesco Chicchiriccò <

ilgro...@apache.org>


wrote:

On 09/04/2018 09:30, Isuranga Perera wrote:

Hi Francesco,


Yes there is @Transactional annotation. But it haven't set the


isolation
property as well as the propagation property. Based on the default
values
set this thread safe problem will still occur. Please correct me
if
I'm
wrong.

The transaction isolation level is set in

https://github.com/apache/syncope/blob/master/core/persisten


ce-jpa/src/main/resources/domains/MasterDomain.xml#L57-L59

Regards.


On Mon, Apr 9, 2018 at 12:20 PM, Francesco Chicchiriccò <

ilgro...@apache.org> wrote:

On 09/04/2018 08:46, Isuranga Perera wrote:

Hi Francesco,

I will take a scenario. Suppose a scenario where thread A & thread

B

try

to login user admin.

   1. thread A checks if a token exist for the user admin
(suppose
  currently there is no token associated with the admin)
   2. Then thread A execute 

Re: Token creation is not thread safe

[Isuranga Perera]

Hi Francesco,

Yes, that will fix the problem.

Best Regards
Isuranga Perera

On Fri, Apr 13, 2018 at 1:00 PM, Francesco Chicchiriccò  wrote:

> Hi,
> after our discussion on PR #70 [1] yesterday, I took the chance to review
> the AccessToken creation logic and committed a change [2] which should fix
> your warnings from SYNCOPE-1301.
>
> Please, take a look at let me know if we can consider SYNCOPE-1301 as
> resolved.
>
> Regards.
>
> [1] https://github.com/apache/syncope/pull/70
> [2] https://github.com/apache/syncope/commit/24f789932141ee05fa1
> 2d81eca9d43178953f508
>
>
> On 09/04/2018 13:19, Isuranga Perera wrote:
>
>> Sure will work on that. I'll give priority to this feature and will
>> continue to work on the eclipse project upon the completion of this one.
>>
>> Best Regards
>> Isuranga Perera
>>
>> On Mon, Apr 9, 2018 at 4:27 PM, Francesco Chicchiriccò <
>> ilgro...@apache.org>
>> wrote:
>>
>> On 09/04/2018 11:24, Isuranga Perera wrote:
>>>
>>> Sure will work on that. Shall I create a JIRA?

 Yes, please.
>>> Do set both 2.0.9 and 2.1.0 as fix-for-versions since I will apply your
>>> PR
>>> both to branches master and 2_0_X.
>>>
>>> Sorry for the delay will submit the ICLA asap
>>> Ok, thanks.
>>>
>>>
>>> Regards.
>>>
>>> On Mon, Apr 9, 2018 at 2:45 PM, Francesco Chicchiriccò <
>>>
 ilgro...@apache.org>
 wrote:

 On 09/04/2018 11:10, Isuranga Perera wrote:

> Since such condition can happen only if the same user tries to login
> from
>
>> 2
>> mediums at the same, this is rarely happen. However that slight chance
>> may
>> prevent that particular user from login to the system until all or
>> all-1
>> access tokens are expired.
>> Using the UNIQUE constraint will definitely will provide a better
>> security
>> and furthermore will make the model more meaningful. On the other hand
>> this
>> will break the token replacing functionality since it first create a
>> token
>> (at this time there are 2 tokens in the db) and delete the last one.
>>
>> What I propose is writing a separate query to replace tokens instead
>> of
>> using save & delete queries separately and furthermore we can use a
>> new
>> query to save tokens without affecting the UNIQUE constraints so that
>> no
>> need to mess with threading & @Transactional properties.
>>
>> If you can come up with a proposal which works with all the supported
>>
> DBMSes, then please go on.
>
> As already asked as comment in your recent PR: did you submit an ICLA
> for
> your contributions? Thanks.
>
> Regards.
>
> On Mon, Apr 9, 2018 at 2:06 PM, Francesco Chicchiriccò <
>
> ilgro...@apache.org>
>> wrote:
>>
>> On 09/04/2018 10:14, Isuranga Perera wrote:
>>
>> The Read Committed isolation level ensures that data can only be read
>>> by
>>>
>>> a
 transaction if it is in the committed state. It doesn't completely
 isolate
 this transaction(create) hence some other transaction can still use
 this
 method which results in the behavior I explained previously. Ideally
 If
 we're gonna use @Transactional annotation the isolation level should
 be
 serialized for create operation. Please correct me If I'm wrong.

 I see your point - while I don't completely agree about the
 likelihood

 of
>>> such race condition to actually happen.
>>>
>>> At worse, you might end up in having two distinct JWT (Access Tokens)
>>> values for a single user, which will anyway be subject to expiration
>>> due
>>> to
>>>
>>> https://github.com/apache/syncope/blob/master/core/provision
>>> ing-java/src/main/java/org/apache/syncope/core/provisioni
>>> ng/java/job/ExpiredAccessTokenCleanup.java
>>>
>>> For additional security, we might want to impose a UNIQUE constraint
>>> on
>>>
>>> https://github.com/apache/syncope/blob/master/core/persisten
>>> ce-jpa/src/main/java/org/apache/syncope/core/persistenc
>>> e/jpa/entity/JPAAccessToken.java#L48
>>>
>>> (not sure to remember why the column is currently set as nullable,
>>> though).
>>> With UNIQUE owner, the step (5) in your sequence below will fail
>>> anyway.
>>>
>>> Again, given the chances that the race condition applies, and
>>> considering
>>> what would be the harm (nearly none, to me), I would rather avoid any
>>> modification rather than imposing the UNIQUE constraint.
>>>
>>>
>>> Regards.
>>>
>>> On Mon, Apr 9, 2018 at 1:12 PM, Francesco Chicchiriccò <
>>>
>>> ilgro...@apache.org>
>>>
 wrote:

 On 09/04/2018 09:30, Isuranga Perera wrote:

 Hi Francesco,

> Yes there is @Transactional 

Re: Token creation is not thread safe

[Francesco Chicchiriccò]

Hi,
after our discussion on PR #70 [1] yesterday, I took the chance to 
review the AccessToken creation logic and committed a change [2] which 
should fix your warnings from SYNCOPE-1301.


Please, take a look at let me know if we can consider SYNCOPE-1301 as 
resolved.


Regards.

[1] https://github.com/apache/syncope/pull/70
[2] 
https://github.com/apache/syncope/commit/24f789932141ee05fa12d81eca9d43178953f508


On 09/04/2018 13:19, Isuranga Perera wrote:

Sure will work on that. I'll give priority to this feature and will
continue to work on the eclipse project upon the completion of this one.

Best Regards
Isuranga Perera

On Mon, Apr 9, 2018 at 4:27 PM, Francesco Chicchiriccò 
wrote:


On 09/04/2018 11:24, Isuranga Perera wrote:


Sure will work on that. Shall I create a JIRA?


Yes, please.
Do set both 2.0.9 and 2.1.0 as fix-for-versions since I will apply your PR
both to branches master and 2_0_X.

Sorry for the delay will submit the ICLA asap
Ok, thanks.


Regards.

On Mon, Apr 9, 2018 at 2:45 PM, Francesco Chicchiriccò <

ilgro...@apache.org>
wrote:

On 09/04/2018 11:10, Isuranga Perera wrote:

Since such condition can happen only if the same user tries to login from

2
mediums at the same, this is rarely happen. However that slight chance
may
prevent that particular user from login to the system until all or all-1
access tokens are expired.
Using the UNIQUE constraint will definitely will provide a better
security
and furthermore will make the model more meaningful. On the other hand
this
will break the token replacing functionality since it first create a
token
(at this time there are 2 tokens in the db) and delete the last one.

What I propose is writing a separate query to replace tokens instead of
using save & delete queries separately and furthermore we can use a new
query to save tokens without affecting the UNIQUE constraints so that no
need to mess with threading & @Transactional properties.

If you can come up with a proposal which works with all the supported

DBMSes, then please go on.

As already asked as comment in your recent PR: did you submit an ICLA for
your contributions? Thanks.

Regards.

On Mon, Apr 9, 2018 at 2:06 PM, Francesco Chicchiriccò <


ilgro...@apache.org>
wrote:

On 09/04/2018 10:14, Isuranga Perera wrote:


The Read Committed isolation level ensures that data can only be read
by


a
transaction if it is in the committed state. It doesn't completely
isolate
this transaction(create) hence some other transaction can still use
this
method which results in the behavior I explained previously. Ideally
If
we're gonna use @Transactional annotation the isolation level should
be
serialized for create operation. Please correct me If I'm wrong.

I see your point - while I don't completely agree about the likelihood


of
such race condition to actually happen.

At worse, you might end up in having two distinct JWT (Access Tokens)
values for a single user, which will anyway be subject to expiration
due
to

https://github.com/apache/syncope/blob/master/core/provision
ing-java/src/main/java/org/apache/syncope/core/provisioni
ng/java/job/ExpiredAccessTokenCleanup.java

For additional security, we might want to impose a UNIQUE constraint on

https://github.com/apache/syncope/blob/master/core/persisten
ce-jpa/src/main/java/org/apache/syncope/core/persistenc
e/jpa/entity/JPAAccessToken.java#L48

(not sure to remember why the column is currently set as nullable,
though).
With UNIQUE owner, the step (5) in your sequence below will fail
anyway.

Again, given the chances that the race condition applies, and
considering
what would be the harm (nearly none, to me), I would rather avoid any
modification rather than imposing the UNIQUE constraint.


Regards.

On Mon, Apr 9, 2018 at 1:12 PM, Francesco Chicchiriccò <

ilgro...@apache.org>

wrote:

On 09/04/2018 09:30, Isuranga Perera wrote:

Hi Francesco,

Yes there is @Transactional annotation. But it haven't set the

isolation
property as well as the propagation property. Based on the default
values
set this thread safe problem will still occur. Please correct me if
I'm
wrong.

The transaction isolation level is set in

https://github.com/apache/syncope/blob/master/core/persisten

ce-jpa/src/main/resources/domains/MasterDomain.xml#L57-L59

Regards.


On Mon, Apr 9, 2018 at 12:20 PM, Francesco Chicchiriccò <

ilgro...@apache.org> wrote:


On 09/04/2018 08:46, Isuranga Perera wrote:

Hi Francesco,


I will take a scenario. Suppose a scenario where thread A & thread
B


try
to login user admin.

  1. thread A checks if a token exist for the user admin
(suppose
 currently there is no token associated with the admin)
  2. Then thread A execute following logic[1] to create and
save
the
token.
  3. Before thread A save the token for user admin thread B
checks
if a
 token exist for user admin (since the toked created by
thread A
is
 not yet saved *exist == null*)
  4. Then thread A 

[jira] [Commented] (SYNCOPE-1301) Token creation is not threadsafe

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436947#comment-16436947
 ] 

ASF subversion and git services commented on SYNCOPE-1301:
--

Commit 6fd572119b1a91029962a7b36ca7f372ad2204a5 in syncope's branch 
refs/heads/2_0_X from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=6fd5721 ]

[SYNCOPE-1301] Reworking logic to avoid conficts


> Token creation is not threadsafe
> 
>
> Key: SYNCOPE-1301
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1301
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.0.8
>Reporter: Isuranga Perera
>Priority: Major
> Fix For: 2.0.9, 2.1.0
>
>
> Token create method in AccessTokenDataBinderImpl[1] is not thread safe. This 
> could result in several problems including
>  * Exist 2 different access token for a particular user at a given time which 
> may result in an exception thrown by method call[2] since it expects a single 
> token a given user.
> In addition to that token replace is implemented as a combination of 2 
> different functionalities. Since the method is not thread safe this may cause 
> some unexpected behaviors (since there can be 2 tokens exist for a particular 
> user. same scenario as above).
> [1] 
> [https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/data/AccessTokenDataBinderImpl.java#L104]
> [2] 
> [https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/data/AccessTokenDataBinderImpl.java#L113]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SYNCOPE-1301) Token creation is not threadsafe

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436948#comment-16436948
 ] 

ASF subversion and git services commented on SYNCOPE-1301:
--

Commit 24f789932141ee05fa12d81eca9d43178953f508 in syncope's branch 
refs/heads/master from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=24f7899 ]

[SYNCOPE-1301] Reworking logic to avoid conficts


> Token creation is not threadsafe
> 
>
> Key: SYNCOPE-1301
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1301
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.0.8
>Reporter: Isuranga Perera
>Priority: Major
> Fix For: 2.0.9, 2.1.0
>
>
> Token create method in AccessTokenDataBinderImpl[1] is not thread safe. This 
> could result in several problems including
>  * Exist 2 different access token for a particular user at a given time which 
> may result in an exception thrown by method call[2] since it expects a single 
> token a given user.
> In addition to that token replace is implemented as a combination of 2 
> different functionalities. Since the method is not thread safe this may cause 
> some unexpected behaviors (since there can be 2 tokens exist for a particular 
> user. same scenario as above).
> [1] 
> [https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/data/AccessTokenDataBinderImpl.java#L104]
> [2] 
> [https://github.com/apache/syncope/blob/master/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/data/AccessTokenDataBinderImpl.java#L113]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Default 'User Workflow' issue

[Francesco Chicchiriccò]

Hi,
see my replies embedded below.

Regards.

On 12/04/2018 21:52, varontron wrote:

Hi,Executed the following:
  In 2.0.9-SNAPSHOT (no extensions), created some users, some in ldap and
pulled, some in Syncope and pushed. All have status = 'Created'


Yes, when using the DefaultUserWorkflowAdapter [1], this is expected.


  Rebuilt and installed 2.0.9-SNAPSHOT with '-P all' to include extensions
  Created a new user successfully in console, assuming workflow took over,
and user has status = 'Active'


Yes, when using the ActivitiUserWorkflowAdapter [2] / 
FlowableUserWorkflowAdapter [3] and the default workflow definition [4] 
[5], this is expected too.



  Could not change any original user's status to 'Active' (how?)
  Attempted to delete users in order to re-add, and incurred error alerts in
console
  Tried a few things, eventually noticed users were successfully deleted from
ldap
  Users still exist in syncope with status = 'Created' and no user-task is
executable
  Can't delete users in syncope, due to 'Empty workflow id'
  Pulling changes from ldap isn't working either perhaps bc of configs.
Is there any option other than dropping db and reloading?


No, no other options: the Workflow Adapter is something that must be 
chosen upfront, and users created under a certain adapter cannot be 
generally manipulated by another adapter.



What is the prescribed method if deploying without Activiti, then say,
adding 100s of users, and then enabling Activiti?  Is there a prescribed
import/export or something?


When using Activiti / Flowable, a workflow instance is started at the 
same time that an user is created; enabling Activiti / Flowable after 
user creation means leaving such user into an inconsistent state.


[1] 
https://github.com/apache/syncope/blob/2_0_X/core/workflow-java/src/main/java/org/apache/syncope/core/workflow/java/DefaultUserWorkflowAdapter.java
[2] 
https://github.com/apache/syncope/blob/2_0_X/core/workflow-activiti/src/main/java/org/apache/syncope/core/workflow/activiti/ActivitiUserWorkflowAdapter.java
[3] 
https://github.com/apache/syncope/blob/2_0_X/core/workflow-flowable/src/main/java/org/apache/syncope/core/workflow/flowable/FlowableUserWorkflowAdapter.java
[4] 
https://github.com/apache/syncope/blob/2_0_X/core/workflow-activiti/src/main/resources/userWorkflow.bpmn20.xml
[5] 
https://github.com/apache/syncope/blob/2_0_X/core/workflow-flowable/src/main/resources/userWorkflow.bpmn20.xml


--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/