-
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
Need request context for resetPassword #512
Comments
See the PR at #337. With the implicit context propagation, you should be able to pick up the context without messing up existing method signatures. |
So the context will somehow be available from an emit? |
@johnsoftek Has the issue been resolved? Can I close it? |
@superkhau AFAIK, no. Context propagation relates to supplying context around a remote request. From memory, ResetPassword is quite strange in that it does not return a result for the original request. Instead the example suggests listening on an emit event. That event does not supply the original request context and therefore the original url is not available. |
@bajtos @raymondfeng @ritch PTAL |
Regarding the current context - see #982. I would expect that if the event is emitted from a HTTP handler, then the event listeners should be able to access the current context even now, before #982 is fixed. As for passing the request context to "resetPasswordRequest", perhaps that can be added to loopback. I am not familiar with the current implementation of "reset pasword", @raymondfeng and/or @ritch now more about that. If they agree it's ok to pass more data to "resetPasswordRequest" event, then a new issue should be opened for that. |
You should use |
+1 |
This still appears to be an issue as I am faced with an identical situation. Attempting app.get('url') returns a URL identical to the one contained in config.json however I need to use a different URL to provide to the user after a "resetPasswordRequest" has been emitted. That URL will change across environments and over time as we have not yet moved to production. Accessing context from the custom method that handles the user's request and is responsible for emitting the "resetPasswordRequest" event is simple enough. But the context is not accessible from the event listener User.on('resetPasswordRequest', function(info)), the listener responsible for acting on the event and dispatching the email. I have followed the example and have a working process with the caveat that I've hard coded the URL to match my local instance. Not to revive an old topic, but I'm very curious as to any progress or workarounds that may exist. |
FWIW, the config can be customized using per-environment overrides like
IMO, this is a missing feature that we should address. Right now, UserModel.remoteMethod(
'resetPassword',
{
description: 'Reset password for a user with email.',
accepts: [
{arg: 'options', type: 'object', required: true, http: {source: 'body'}},
],
http: {verb: 'post', path: '/reset'},
}
); I am proposing to rename the first argument from UserModel.emit('resetPasswordRequest', {
- email: options.email,
+ email: params.email,
accessToken: accessToken,
user: user,
- options: options,
+ options: params,
+ }, options);
}); Thoughts? @tjc0090 would you like to contribute this change yourself? I am happy to help you along the way. See http://loopback.io/doc/en/contrib/code-contrib.html to get you started. |
I use:
I should probably store the origin in ctx.options... |
Is there a workaround for accessing the current context on resetPasswordRequest? https://loopback.io/doc/en/lb3/Using-current-context.html doesn't show how to access the current context in such situation. The reason I need this is for using i18n-node translation function, which is attached to both req and res properties of the context object. I'm able to localize messages on any remote methods and operation hooks, because I have access to the context object. |
I don't think there is a workaround, but see my #512 (comment) for a pointer on how to fix this problem. I am happy to help you along the way if you decide to contribute this fix. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hopefully this is fixed in Loopback 4, so for now I'll just do like @johnsoftek with the following:
|
Loopback should generally not need to know the URL on which it is listening.
However, there are several situations where a URL must be generated for the user to connect back. For example, User.verify and User.resetPassword. In both those cases, we need to create a link to embed in an email for the user to confirm an action by verifying their email address.
At present, both functions require host and port to be configured in config.json or related config.
Another approach is to use the URL of the request to construct a link. I did this in an afterRemote hook on User.create:
So registration works fine with the inbound URL.
But I have a problem with resetPassword. I listen on "resetPasswordRequest" event but I have no context of the incoming message to determine the URL.
Is there any way at present to get the context? Or is it a feature request?
The text was updated successfully, but these errors were encountered: