-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Assume login feature #2740
Assume login feature #2740
Conversation
… unneeded code in StatelessAuthenticationFilter
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.
I have added just minor suggestions about the IT. The only coding issue is related to the use of an instance attribute in the Spring Security Filter that should be removed (maybe refactoring the code to use a custom exception)
|
||
@Override | ||
public String[] getSupportedTypes() { | ||
return new String[] { SiteRest.CATEGORY + "." + SiteRest.NAME }; |
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.
I suggest to support also EPersonRest object as we will need a way to inform the UI that the loginAs can or cannot be used on a specific user (You cannot assume the login of another admin in the current version)
@@ -1325,4 +1341,113 @@ private String getAuthorizationID(String epersonUuid, String featureName, String | |||
+ id.toString(); | |||
} | |||
|
|||
@Test | |||
public void loginOnBehalfOfTest() throws Exception { |
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.
please move this test in a dedicated class. This class should contains only general tests to validate the authorization framework and not specific features. See for instance https://github.com/DSpace/DSpace/blob/0039b309d11e3d55a2a92699b25458fe9bfc4740/dspace-server-webapp/src/test/java/org/dspace/app/rest/authorization/WithdrawFeatureRestIT.java
.param("eperson", String.valueOf(eperson.getID())) | ||
.param("feature", loginOnBehalfOf.getName())) | ||
.andExpect(status().isOk()) | ||
.andExpect(jsonPath("$._embedded.authorizations", Matchers.not( |
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.
I would suggest to check for an empty list here instead than exclude the authorization object
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.
@abollini We can't test on an empty list here as some features are always returned by default. For example the "AlwaysTrueFeature". As we can't anticipate which features will be returned it would be best to check for an exclusion.
.andExpect(status().isOk()) | ||
.andExpect(jsonPath("$._embedded.authorizations", Matchers.not( | ||
Matchers.hasItem(AuthorizationMatcher.matchAuthorization(loginOnBehalfOfAuthorization))))); | ||
} | ||
} |
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.
we should have test to verify that we cannot loginas another admin
|
||
private ConfigurationService configurationService = DSpaceServicesFactory.getInstance().getConfigurationService(); | ||
|
||
private boolean inErrorOnBehalfOf = false; |
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.
this cannot be an instance attribute otherwise there are issue when multiple login request are processed at the same time
|
||
@Before | ||
public void setup() { | ||
context.turnOffAuthorisationSystem(); |
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 is not really needed, we can simplify the code here
|
||
@Test | ||
public void loggedInUserPropertyFalseTest() throws Exception { | ||
context.turnOffAuthorisationSystem(); |
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.
the turnOff is not really needed
.header("X-On-Behalf-Of", eperson.getID())) | ||
.andExpect(status().isBadRequest()); | ||
|
||
context.turnOffAuthorisationSystem(); |
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.
I would suggest to don't revert the configuration manually here the change as this is already done in a Before method (just to avoid in future confusion in other developers)
dspace-server-webapp/src/test/java/org/dspace/app/rest/LoginAsEPersonIT.java
Show resolved
Hide resolved
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.
...-server-webapp/src/main/java/org/dspace/app/rest/security/StatelessAuthenticationFilter.java
Outdated
Show resolved
Hide resolved
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.
I've deployed and tested this branch, and I couldn't see any problems.
I was able to verify:
- Without
webui.user.assumelogin = true
theX-On-Behalf-Of
header is denied - With
webui.user.assumelogin = true
the pages return the content based on the user's permissions, including e.g. the workflow tasks, or claiming a workflow task - With
webui.user.assumelogin = true
the pages return forbidden for pages the user is not authorized to use
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.
@KevinVdV : I gave this another review today. While I think it's looking better, the Pair
logic seems really odd to me. I'd like to either better understand why you decided on this route (which means better code commenting here), or replace it with normal error handling. See more inline below.
...rver-webapp/src/main/java/org/dspace/app/rest/authorization/impl/LoginOnBehalfOfFeature.java
Show resolved
Hide resolved
...-server-webapp/src/main/java/org/dspace/app/rest/security/StatelessAuthenticationFilter.java
Outdated
Show resolved
Hide resolved
...-server-webapp/src/main/java/org/dspace/app/rest/security/StatelessAuthenticationFilter.java
Outdated
Show resolved
Hide resolved
@tdonohue We have processed your feedback, can you review again ? |
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.
thanks @Raf-atmire to have addressed my feedback. I have just added a small cleanup comment inline
dspace-server-webapp/src/test/java/org/dspace/app/rest/AuthorizationRestRepositoryIT.java
Outdated
Show resolved
Hide resolved
...-server-webapp/src/main/java/org/dspace/app/rest/security/StatelessAuthenticationFilter.java
Show resolved
Hide resolved
all my feedback have been processed. Can be merged once @tdonohue is satisfied |
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.
👍 Looks good to me now. Thanks @KevinVdV and @Raf-atmire
References
Add references/links to any related tickets or PRs. These may include:
Description
Rest api implementation for the assume login feature. Included are the actual "login as" implementation by making use of the "X-On-Behalf-Of" header & code to support "loginOnBehalfOf" on the "features" feature.
Instructions for Reviewers
Please add a more detailed description of the changes made by your PR. At a minimum, providing a bulleted list of changes in your PR is helpful to reviewers.
List of changes in this PR:
Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!
400 Bad Request
,401 Unauthorized
,403 Forbidden
,404 Not Found
, etc)pom.xml
), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.