One thing you could do is send them an email with a fresh login link. You could catch the 'login failed' and generate a new magic link (which you could build via the API). Then you'd send them an email with the new magic link.

You could also make sure you include when the link expires in the subject line of the email.

More on doing that here: https://fusionauth.io/community/forum/topic/220/can-i-customize-the-passwordless-link-email-subject-with-the-time-the-link-expires

Back to my issue with the page a user who presses the button after the session has expired (see above). Is there any way to tell FA where to redirect to when the link has expired.

From reading the passwordless guide, it looks like an Invalid login credentials message will be displayed in this case. That may be themeable, but I'd have to play around to know for sure. But that's where I'd start.

@richb201 said in Invalid redirect uri:

If not is there a suggestion box?

This is the suggestion box :). We also accept PRs against our documentation site: https://github.com/fusionauth/fusionauth-site/

However, it's best to open a new topic when there's a new question or issue. Otherwise things can sometimes get lost.

I'm glad you are making progress!

Is the user for which you are trying to generate a JWT refresh token associated with the application?

That is, have they "registered"?

You can do that in the user details screen.

I think this is a bug. For some reason the tenant settings are controlling on the refresh token exchange when the application config should take precedence.

Can you please file an issue here: https://github.com/fusionauth/fusionauth-issues/issues and reference this forum post?

@andre said in FUSIONAUTH_KICKSTART is deprecated, what is the new name?:

FUSIONAUTH_APP_KICKSTART_FILE

Actually FUSIONAUTH_APP_KICKSTART_FILE works.

I am not using elastic search. But I thank you for your help, but I am getting to it a different way. I have stuffed the use's email into the "state" variable and then on the app side I am using that as an index. So while it is not the most "pretty" solution, I think it might work.

Upgrading to v 1.19.7 seemed to work. thx

That is one path that might work in the future, but you can't create arbitrary registrations, call the APIs, or know which groups someone is part of right now.

I know the roadmap includes reworking the lambda so that it is more flexible. That's tied up in upgrading from Nashorn. If we allowed you access to any APIs from the lambda, you'd then be able to do this.

See https://github.com/FusionAuth/fusionauth-issues/issues/571 and https://github.com/FusionAuth/fusionauth-issues/issues/267 for more on that. If you can, it'd be great to comment pointing to this forum post about wanting more flexibility in Lambdas.

You can implement any password hashing scheme as a plugin and load it into FusionAuth. Then you simply migrate the user using new scheme. There is a tutorial on that matter in the docs.

Nope, there's no way to know when passwordless logins have expired via webhook.

You have a couple of options:

You can create a github issue specifying your use case. I'm not sure how quickly this feature would be implemented, however, as this is the first request I've seen. You could note when you send the passwordless login on the user object (in user.data) and build a query that shows all the users with expired passwordless logins. You can know when you sent it and how long it is good for by querying the tenant settings, which gives you the time it expires. You could note when you send the passwordless login in some other external database and process it there.

Added a doc bug: https://github.com/fusionauth/fusionauth-issues/issues/1005

Hiya,

Can you please provide more details:

any logs (esp with debug enabled) what version of FusionAuth are you running? configuration of the SAML provider, including everything outlined here: https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/ what docs you used on the okta side

I know we have customers who have succeeded in using Okta as the Idp and FusionAuth as the SP, so would love to get to the bottom of this.

Hiya,

Do you have a script or set of scripts which illustrates a valid user enumeration attack against FusionAuth?

I did a test of three kinds of user login:

existing user, valid password existing user, invalid password user who didn't exist

And they all returned in roughly the same amount of time.