Skip to content
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

Add support for collections and iterables to authZ generators #761

Merged
merged 3 commits into from Dec 5, 2016
Merged

Add support for collections and iterables to authZ generators #761

merged 3 commits into from Dec 5, 2016

Conversation

mmoayyed
Copy link
Contributor

@mmoayyed mmoayyed commented Dec 1, 2016

Closes #758

@leleuj
Copy link
Member

leleuj commented Dec 1, 2016

+1

private final String[] permissionAttributes;


private final Iterable<String> roleAttributes;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could have Collection everywhere, as in the other class? I'm not so clear about the difference between using Iterable or Collection in this context... I feel like Collection is the main way to represent a collection of something, Iterable seems too low level in a way. Not sure :)

return Arrays.copyOf(original, original.length);
public FromAttributesAuthorizationGenerator(final String[] roleAttributes, final String[] permissionAttributes) {
if (roleAttributes != null) {
this.roleAttributes = Arrays.asList(roleAttributes);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Careful, the behaviour is a little changed: Arrays.copyOf was making a copy, while Arrays.asList use the array itself as the backend of an ArrayList; changes to the array will be reflected in the ArrayList.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What sort of changes to the array do you have in mind? Could you demonstrate that with an example perhaps?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking of this kind or that kind of best practice.

Basically in object oriented programming, the object encapsulates data and if this data is directly modifiable by an external object, then you have a problem. So when you can, you should copy mutable data in prevention, in particular when you don't have responsibility of the code that will call the concerned method. It's a very basic best practice and it was already enforced in the previous code you modify here, so I thought it would be best to continue with that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't think of a practical scenario in this case where that would make sense. If you insist, I can make a change, sure, but I don't see how this applies really.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do as you wish, sorry for the bother :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh no worries at all. Thanks. I understand the principal and I don't mind it at all; mostly wanted to see if there was anything concrete that I should pay closer attention to. Updates coming up.

@leleuj leleuj merged commit c44134d into pac4j:master Dec 5, 2016
papegaaij pushed a commit to topicusonderwijs/pac4j that referenced this pull request Jun 26, 2019
)

* Add support for collections and iterables to authZ generators

* removed pmd issues

* Add support for collections and iterables to authZ generators
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants