-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Documentation for AccessToken invalidation #3112
Comments
We should update the documentation ASAP, we have already had a customer asking about the warning printed by recent LoopBack 2.x versions. Below is my response, some of the information can be reused in the docs. Some time ago, we have fixed a security vulnerability in LoopBack. The fix was viewed as backwards-incompatible by some LoopBack users, therefore we introduced a feature flag to enable/disable the fix in 2.x LTS line. The purpose of the new warning is to educate upgrading users about the vulnerability and let them decide how to handle it. The gist of the vulnerability: when user's account is compromised (e.g. a password is leaked), then the user needs to log out other sessions after changing password to a new (not compromised) one, so that attacker's sessions are invalidated and the attacker can no longer access the system. // server/config.json
{
"port": 3000,
// ...
"logoutSessionsOnSensitiveChanges": true
}
// common/models/my-user.json
{
"name": "MyUser",
"base": "User",
// ...
"injectOptionsFromRemoteContext": true
} |
@bajtos Thank you for opening this ticket. It's unclear what Because of the whole context stuff issue I have setup a test environment trying to get rid off loopback-context and use the option approach. From your docs
It doesn't matter if I set |
It adds an
Yes, you have to describe the
I see your point, in hindsight the name Could you please contribute the documentation improvement? Here is the source code of "Using-current-context" page: And here are instructions for contributing to our documentation: BTW this discussion is off-topic here. If there is anything else to discuss in relation to |
@bajtos Thank you for the detailed answer. I will contribute the documentation improvement for both versions. |
injectOptionsFromRemoteContext is unclear that it should only be applied to 2.x because on 3.x it gives an error message
where we can see its clearly not working with built in 'access' or 'loaded' hooks. |
Hello, the documentation change was already landed few days ago, see loopbackio/loopback.io#258 @michaelfreund could you please take a look and send a new pull request if there is any information missing?
Please open a new issue and provide a small app reproducing the issue per our bug reporting instructions. |
Just reviewed 👍 looks good. |
@bajtos there is still some information missing. I will send a pull request with corresponding updates. But before, let's clarify some more facts.
customerModel.updateCurrentUser = function (data, options, next) {
customerModel.findOne(query, function (err, customer) {
customer.updateAttributes(data, options); ///< pass options explicitly
});
};
|
Oh, that's an oversight. The very purpose of
Excellent 🙇
Yes.
Yes.
Yes. You also need your
Yes. I would also recommend to explicitly disable all remote methods in the built-in User object that could be used to modify user data. I.e. don't rely on the fact that your client apps are calling I think it's ok to describe this use case in the documentation too, as long as the other use case (a custom model extending User and enabling cc @crandmck |
Fix User model to preserve the current session (provided via "options.accessToken") when invalidating access tokens after a change of email or password property.
There is a sudden issue from the blue, regarding invalidation:
such as? in user.js
Why would you do it? Why is it neccessary to hardcode this logic? |
See #3112 (comment) and also https://loopback.io//doc/en/lb2/AccessToken-invalidation.html
In #3071, I proposed a feature allowing app developers to get more control over access-token invalidation. It may be what you are looking for. |
Update our documentation to describe all recent changes (and the new config options) related to access token invalidation
The text was updated successfully, but these errors were encountered: