Yes - I saw you had made comment as well for something like
role.removePermission() and related methods which are not there yet. I
think it is probably cleaner to keep it in the security manager as all
the other methods are already there (simpler to reference than knowing
the Role and Group objects have their own add/remove methods). But I am
open either way.
And you are right, in my last update to the turbine-flux module, I was
testing removing a role, and it was failing if the role was still linked
to a user... I simply made a method to remove related users before
removing the role, and that cleared it up for me.
I think this is the proper logic. Feel free to correct me if I am wrong :-)
Group removal
1. Remove linked user/group/role in TURBINE_USER_GROUP_ROLE
2. Remove from TURBINE_GROUP
Group revoke: (Same as above with step 2)
Role removal (Would impact all groups and users)
1. remove linked users in TURBINE_USER_ROLE
2. remove linked permissions in TURBINE_ROLE_PERMISSION
3. remove from TURBINE_ROLE
Role revoke: just remove the entry in TURBINE_USER_ROLE for a single user
(Unless we were to implement a TURBINE_GROUP_ROLE relationship - see below)
Permission removal (impacts all associated roles)
1. remove from all associated roles in TURBINE_ROLE_PERMISSION
2. remove from TURBINE_PERMISSION
Permission revoke: only works at the role level - permissions are not
directly assigned to users
1. remove entry from TURBINE_ROLE_PERMISSION
2. do not delete from TURBINE_PERMISSION (does not affect other roles)
After thoughts:
Are we missing something here? Thinking that a group could encompass a
set of roles?
TURBINE_GROUP_ROLE (link roles to a group?) Nothing like this
currently exists.
I was never sure otherwise how the group object might be useful. If so,
this would obviously change cascade effects for revoking a user from a
group, but if not, wouldn't revoke group just essentially be remove
group without removing the group from the TURBINE_GROUP table?
Thoughts? How do you currently use groups?
--
Jeff
On 12/13/2017 11:13 AM, Georg Kallidis wrote:
Hi Jeff,
I 've updated Turbine Webapp with more complex tests.
This is not yet in the repo:
@FulcrumSecurityTorqueModelManager
- We may be aware of the grant behaviour of Fulcrum Security Torque
ModelManager namely, that all relationships are cleaned up for each object
before updating, that is all relationships are refreshed. This happenss in
one big transaction and should be save. Where there might be issues, is
that for one one object there might be a lot of relationships, not for a
user I presumably, but for some group and/or role. It might be, that one
role grant have to clean up 1000s of entries or more, as this might be a
role/group shared by many. Actually this is not even needed at all, as the
user update does already cleanup the relationship table! As a result, I
would remove the group and role database update in the grant method.
revokeAll(Group)
- I would like to add a Turbine Default Security method revokeAll(Group)
which revokes all entries, any rights/roles for any user in this specific
group (may be excluding global or Turbine). But may be I overlooked
something ... ?
Best regards, Georg
Von: Jeffery Painter <[email protected]>
An: [email protected]
Datum: 13.12.2017 16:26
Betreff: Re: [RESULT] [VOTE] Release: Turbine-Webapp 1.0.2
archetype targeting Turbine4 on staged repository
Hi Georg,
I have merged your pull request in github for turbine-flux and made a
few minor cleanups (updating licenses etc). All seems to be working
well, and I am using it in my own application without any trouble.
Thanks for all your help on making the necessary changes to security
manager. Let me know what I can do to help with pushing the next release.
I will download your updates to turbine webapp and see if there is
anything I can do there.
--
Jeff
On 12/12/2017 04:08 AM, Georg Kallidis wrote:
Hi all,
as a result we have two binding votes for the release candidate
[binding]
+1 - Georg Kallidis
-1 - Jeffery Painter
The result is we cancel this RC (dropping the artefacts, ..).
Following the communitys discussion in the dev mailing list the
suggested
workflow would be:
- first to release two modules already in preparation with bugfixes,
- only after this is done the Turbine Webapp RC will follow.
In a sum, the projects next RCs in question for this issue are:
(1) Security Fulcrum v1.1.2
(2) Turbine v4.0.1 (depends on 1)
(3) Turbine Webapp 1.2 (depends on 1,2)
Comments (and commits) welcome!
Best regards, Georg
Von: "Georg Kallidis" <[email protected]>
An: "Turbine Developers List" <[email protected]>
Datum: 08.12.2017 14:22
Betreff: Re: Re: [VOTE] Release: Turbine-Webapp 1.0.2 archetype
targeting Turbine4 on staged repository
Hi,
please read also the forwarded e-mail below from Jeffery. Jeffery´s
proposal may be the fastest way to release, what we already know has to
be
done.
But we may be aware, that SOME bugs may always be hidden in ANY release
and I would NORMALLY suggest to always complete a Turbine release with
an
Turbine Webapp release.
As a result, if nobody complains (i.e. we get only unanimous consent,
"do
not care" remarks or no reply at all), I'll continue by sending a
VOTE/RESULT around beginning of next week proposing to
- drop the current Turbine webapp RC
- targeting instead for the following RCs in this order:
(1) Security Fulcrum v1.2 - still some more checks needed
(2) Turbine v4.0.1 -
(3) Turbine Webapp 1.2 - double checking (1) and (2) with tests in
SNAPSHOT mode
If someone else wants to help out, let me know it!
Best regards, Georg
Von: Jeffery Painter <[email protected]>
An: Georg Kallidis <[email protected]>
Datum: 08.12.2017 13:05
Betreff: Re: [VOTE] Release: Turbine-Webapp 1.0.2 archetype
targeting Turbine4 on staged repository
I think that is a good plan. I have no other issues with Turbine
4.0.1-SNAPSHOT release at this time (after fixing the input.encoding
issue). And the patches you've made to fulcrum-security seem to work
"well enough" for most use cases and we have identified what needs to be
addressed going forward. Again, I don't use permissions (but after
working on the Flux system, it looks like something I might use in the
future), so I am happy we have been giving those a thorough test.
I would go ahead and push those artifacts as soon as you feel is
appropriate.
On 12/08/2017 02:33 AM, Georg Kallidis wrote:
we may indeed decide to proceed to Turbine 4.0.1, but we have to keep
in
mind then, that no Turbine Webapp would exist ready at hand to test
Turbine 4.0. Turbine 4.0 could be used in many, if not most parts. For
the
security services you could use Fulcrum instead of Turbine (cft. to the
test examples), the one exception is permission revoke/grant, which
must
be fixed in Fulcrum. Of course we may find other fixables.
If cancelling this release, we may then update NOW (after deciding
process
is finished) Turbine Webapp to be based on Turbine 4.0.1-SNAPSHOT and
Fulcrum Security 1.1.2-SNAPSHOT. As a result we have to release 4.0.1
and
1.1.2 before the next Turbine Webapp 1.0.2. Then we may (or may not)
include the Turbine - Flex module!?
Best regards, Georg
Von: Jeffery Painter <[email protected]>
An: [email protected]
Datum: 07.12.2017 17:59
Betreff: Re: [VOTE] Release: Turbine-Webapp 1.0.2 archetype
targeting Turbine4 on staged repository
[ ] +1 release it
[ ] +0 go ahead I don't care
[X] -1 no, do not release it because
I think we should delay the release until we finish fixing the few
remaining bugs in fulcrum-security and also use the patched turbine
4.0.1 core. Then we can point the new archetype at those instead, and I
can work on completing the turbine-flux module if you would like to
include it.
Thanks!
Jeff
On 12/05/2017 09:20 AM, Georg Kallidis wrote:
Hi all,
a release candidate for the
Turbine Webapp Maven-Archetype, version 1.0.2
has been prepared!
It contains the archetype for Turbine 4.0 Version.
Tag: https://svn.apache.org/repos/asf
/turbine/maven/archetypes/tags/turbine-webapp-4.0-1.0.2
Artifacts:
https://repository.apache.org/content/repositories/orgapacheturbine-1026
Major changes are
- Now based on Turbine 4.0!
- Added some more examples (JSON, Localization, ..)
- Schema changed using by default MySQL autoincrement instead of
Torque
id
broker.
- JUnit Tests added to generated archetype project (mainly checking
security managers) requiring MySQL, Torque Fulcrum Security and in
parts
Turbine. Part of the tests may only succeed in Turbine 4.0.1 version,
and
are ignored. Tests must be activated manually with mvn test
-DskipTests=false, more info in archetype folder docs/README.txt.
- SLF4J support added
Next steps:
- Update to Turbine 4.0.1
- include Flex (Jar?) into Web App 1.0.3
Please verify this release candidate carefully and vote!
[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because
Best Regards, Georg
---------------------------------------------------------------------
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]
--
Jeff Painter
CEO and Founder of JiveCast
Software and analytics, made together
http://jivecast.com
301 Fayetteville St. Unit 2301, Raleigh, NC 27601
(919) 533-9024
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
