-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Treat user authorities as roles #13
Treat user authorities as roles #13
Conversation
return true; | ||
} | ||
} | ||
} catch (Exception e) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be logging at least
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. I just preserved the original behaviour of doing nothing when the role verification fails. But I admit that using Exception is too wide. I'll narrow it. You sure logging could be a good idea?
@bkmeneguello I'm aware about the performance impact of the change. The change is going to embedded user loading from security realms and sequential role checks for every SID missing in the group. Since it's a common case for the fine-grain security, the overall calculation time may seriously degrade. Have you evaluated it? |
@@ -77,6 +77,24 @@ | |||
<version>1.14</version> | |||
<type>jar</type> | |||
</dependency> | |||
<dependency> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wrong intend
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be better to solve architectural issues before rat-holing into this topic...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. Thanks!
49aeab5
to
f95cc99
Compare
f95cc99
to
7b5a518
Compare
@oleg-nenashev So do you had reviewed my last comments? |
Ok, today I got what you mean. My server become unusable because of a new LDAP ACL that caused slowness. |
@bkmeneguello |
@oleg-nenashev I've implemented the cache, a simple solution. In your opinion the cache parameters (max-size, ttl and concurrency) should be parameterized in a view? These entire feature should be an opt-in? |
ad084d7
to
54b04a3
Compare
bump? |
@bkmeneguello Thanks for the reminder. I was extremely busy with some personal things, but hopefully I'll be able to process incoming PRs on this NY break |
|
||
private final Cache<String, UserDetails> cache = CacheBuilder.newBuilder() | ||
.softValues() | ||
.maximumSize(100) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs to be a global configuration/system property. 100 is a good default value, but I can imagine installation requiring more users
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. But this value of 100 is the cache size. Just the 100 LRU entries will be cached.
@oleg-nenashev do you agree with my last replies? |
@bkmeneguello |
Thanks! |
@oleg-nenashev pls, did you had time to review this PR? |
@bkmeneguello |
Thanks! |
Looking for the issue to reference it during the merge. It exists AFAIK. |
Caused performance regressions, hence the feature will be partially disabled in #18 |
absolutely ok |
This is useful in combination with other plugins, like LDAP Authentication to treat groups as roles.
Also I've added two tests. One covering the basic working flow and another to check if authorities are being treated as roles.