You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If someone makes the mistake of trying to access springSecurityService.principal during grails bootstrap (which will be null), when a user finally logs in their security object gets pinned into memory.
The next 5-10 requests will use the previous users credentials, even if no bearer token or JSESSIONID is provided.
Here is the output of a script showing the problem. I access a protected resource and get rejected (correct behaviour), then I log in, and try and get the resource again, but don't send a bearer token. The system lets me in and thinks I am the logged in user.
It has a single secured controller exposing a "whoami" endpoint.
The "BUG" only happens if Bootstrap tries to get the principal object.
I can't determine exactly when the credentials are finally removed. I think it is when the thread that processed the login finally comes around and processes another request.
Here are (I think) the relevant lines from application.groovy.
and Urlmappings.groovy "/app/$action?/$id?(.$format)?"(controller: "app")
and the Controller code.
@Secured('isAuthenticated()')
class AppController {
@SuppressWarnings('unused')
static responseFormats = ['json', 'xml']
SpringSecurityService springSecurityService
def whoami() {
def principal = springSecurityService.getPrincipal() ?: [message: "No principal defined"]
render principal as JSON
}
}
This code is all brand new to me, but the issue might be around line 114 of RestAuthenticationFilter.groovy.
It stores the access token in a Static Holder. I think that trying to access the principal object from Bootstrap might be interacting with that context in a weird way.
The text was updated successfully, but these errors were encountered:
If someone makes the mistake of trying to access springSecurityService.principal during grails bootstrap (which will be null), when a user finally logs in their security object gets pinned into memory.
The next 5-10 requests will use the previous users credentials, even if no bearer token or JSESSIONID is provided.
Here is the output of a script showing the problem. I access a protected resource and get rejected (correct behaviour), then I log in, and try and get the resource again, but don't send a bearer token. The system lets me in and thinks I am the logged in user.
https://github.com/tircnf/springSecurityRest
I've included the source code to the app on github:
https://github.com/tircnf/springSecurityRest
It has a single secured controller exposing a "whoami" endpoint.
The "BUG" only happens if Bootstrap tries to get the principal object.
I can't determine exactly when the credentials are finally removed. I think it is when the thread that processed the login finally comes around and processes another request.
Here are (I think) the relevant lines from application.groovy.
and Urlmappings.groovy
"/app/$action?/$id?(.$format)?"(controller: "app")
and the Controller code.
This code is all brand new to me, but the issue might be around line 114 of RestAuthenticationFilter.groovy.
It stores the access token in a Static Holder. I think that trying to access the principal object from Bootstrap might be interacting with that context in a weird way.
The text was updated successfully, but these errors were encountered: