and discuss Identity API
---
Key: DELTASPIKE-77
URL: https://issues.apache.org/jira/browse/DELTASPIKE-77
Project: DeltaSpike
Issue Type: Sub-task
Components: Security-Module
Affects Versions: 0.1
with it. (details are available at http://s.apache.org/w1)
review and discuss Identity API
---
Key: DELTASPIKE-77
URL: https://issues.apache.org/jira/browse/DELTASPIKE-77
Project: DeltaSpike
Issue
Identity API
---
Key: DELTASPIKE-77
URL: https://issues.apache.org/jira/browse/DELTASPIKE-77
Project: DeltaSpike
Issue Type: Sub-task
Components: Security-Module
Affects Versions: 0.1-incubating
Identity API
---
Key: DELTASPIKE-77
URL: https://issues.apache.org/jira/browse/DELTASPIKE-77
Project: DeltaSpike
Issue Type: Sub-task
Components: Security-Module
Affects Versions: 0.1-incubating
On 13/02/12 19:47, Boleslaw Dawidowicz wrote:
On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote:
Some particular points to review:
1. Should we attempt to use the security classes provided by Java SE, such as
Principal, Subject, etc or use our own User API - this will affect what is
returned
On 13/02/12 18:15, Rudy De Busscher wrote:
Hi,
I think it is also important that you can work with permissions. It is
much more fine grained then roles but more flexible. It becomes much easier
to change what a group of people can do, even without changing the code. I
never use roles in an
Identity API (was: review and
discuss Identity)
review and discuss Identity API
---
Key: DELTASPIKE-77
URL: https://issues.apache.org/jira/browse/DELTASPIKE-77
Project: DeltaSpike
Issue Type: Sub-task
Hi,
I think it is also important that you can work with permissions. It is
much more fine grained then roles but more flexible. It becomes much easier
to change what a group of people can do, even without changing the code. I
never use roles in an application, only permissions.
I'm not saying
On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote:
Some particular points to review:
1. Should we attempt to use the security classes provided by Java SE, such as
Principal, Subject, etc or use our own User API - this will affect what is
returned by the getUser() method above. Keep in
hi shane,
i'm sure there are good reasons for most/all details. since i don't know
them, i just list the topics which come to my mind after reading the
provided information.
#tryLogin
i don't see the need for it compared to #login, because it can be done by
users easily (if needed).
at least at
I've created an umbrella issue to track the work we do on the security
module [1], and the first task is to review and discuss the Identity
API. This API forms the core of the security module, and all other
features build on top of it to implement a complete security framework.
The Identity
11 matches
Mail list logo