Posts made by Alex Patterson

@aman-c FusionAuth is completely running outside of Next.js. So it all depends on what you are using to make the call to FusionAuth.

My suggestion would be to implement a version of our React SDK
https://fusionauth.io/docs/sdks/react-sdk

Then anything clientside that needs details you can use the built in hooks, anything serverside you can use the cookie that sits at app.at or for identity app.idt.

If you have been using our quickstart you are most likely using next-auth which could be causing issues with the implementation. We have had a lot of internal discussion about removing this methodology moving forward to simplify our Next.js suggested implementation.

You can find out more about our cookies that are set in our Hosted Backend details.
https://fusionauth.io/docs/apis/hosted-backend

I believe what you are seeing is the consent mode, you can find more details on this

https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/scopes#form-fields

The /oauth2/consent endpoint in FusionAuth is used for handling user consent during the OAuth process. It provides several variables that can be used to customize the consent prompt:
action: The action the user selected on the consent prompt. The value should be allow if the user made consent selections and wants to continue or cancel if they have decided not to continue.
optionalScopes: The list of OAuth scopes on the request with optional user consent.
requiredScopes: The list of OAuth scopes on the request that require user consent.
scopeConsents: A map of OAuth scope consent choices made by the user. The key into the map is the OAuth scope name. The value should be true if the user has consented to the scope or false if they have declined.
unknownScopes: The list of unknown OAuth scope names on the request if the application is configured to Allow unknown scopes.
These variables are available since version 1.50.0 of FusionAuth.

This can also be used in theming.

https://fusionauth.io/docs/customize/look-and-feel/template-variables#oauth-consent-prompt

@aman-c do you have a repo available for this?

Also what are you trying to use next-client-cookies for in the app? Is it in a client-side only app?

Are you trying to access app.at to get the Auth cookie?

@bubblez there was also a change in 1.50 (so I am surprised if you were on 1.51 if this would happen) where we stopped sending email to the app.id JWT and only provide this within app.idt.

I would recommend updating the code accordingly if you are still using this method.

An alternative but not suggested is to change your scope handling policy to Compatibility which will send this again in your app.id.

@bubblez do you have the scope correctly set within your Identiy provider?

I am testing this now locally to see if there is a difference on the versions.

@aswetnatex

docker pull fusionauth/fusionauth-app:latest

@milton-jesus awesome glad you solved it!!

@milton-jesus is there a requirement leaving you on 1.15.8?

Have you tried with latest?

https://fusionauth.io/docs/release-notes/

@tschlegel thank you for reporting! This appears to be a bug. I have created the same issue within our GitHub issues page to follow up with, feel free to follow over there for status. I have prompted the engineering team as well so it gets on our "short" list.

https://github.com/FusionAuth/fusionauth-issues/issues/2863

Hey, are you interested in learning more about JSON Web Tokens and how to protect your APIs with them?

Join my talk hosted by the great peeps at Gun.io!

https://www.meetup.com/gundotio/events/302264818/

@ronn316 if you want to use silent mode during the upgrade

https://fusionauth.io/docs/get-started/download-and-install/silent-mode

@itai This is what exists today, the team is working on more features for webhooks in upcoming releases.

FusionAuth provides certain guarantees when it comes to the delivery of webhooks. These guarantees are determined by the transaction level that you set for your webhooks. The transaction level can be one of the following:

• "No webhooks are required to succeed": In this case, FusionAuth will "fire and forget" the webhooks. Even if all webhooks fail, the operation (like a user update) will still succeed (source).

• "Any single webhook must succeed": If at least one webhook succeeds, the operation will succeed. If all webhooks fail, the operation will fail. FusionAuth will retry failed webhooks up to three additional times (source).

• "All webhooks must succeed": Every single webhook must succeed for the operation to succeed. If any webhook fails, the operation will fail (source).

In case of failures, FusionAuth will retry sending the payload up to three additional times. If a webhook endpoint times out, this is considered a failure, the same as if a non 2xx status code is returned. If the endpoint does not respond after the retries, the failure will be logged in the system log (source).

It's important to note that if a webhook is transactional and returns a non 2xx status code, the corresponding action will not succeed. For example, if a user login triggers a webhook and the webhook fails, the user won’t be able to log in (source).

JavaMail settings in FusionAuth can be configured under the SMTP settings of a tenant. You can access these settings by navigating to Tenants > Edit > Advanced > SMTP settings. Here, you can add additional properties for JavaMail.

For example, to enable debug mode, you can add mail.debug=true to the additional properties. This will provide more verbose logging for SMTP, which can be helpful for troubleshooting email issues. The debug logs can be viewed under System > Logs and selecting fusionauth-app.log source.

In some cases, you might need to set timeouts for the SMTP connection. This can be done by adding the following properties:

mail.smtp.connectiontimeout=2000
mail.smtp.timeout=2000

These settings will set the read and write timeouts to 2 seconds (2000 ms) source.

If you're experiencing issues with email delivery, it might be helpful to change the SMTP port or switch between TLS and SSL, especially if you're using a cloud service like FusionAuth Cloud, which has certain restrictions on ports source.

Remember to be cautious when enabling debug mode or changing other settings, as it could potentially lead to a large volume of logs or affect the performance of your application.

@evanm Yes you can use the sub inside of the JWT when making any API call to your backend. In your database this will be a unique Id for the user. You can even get more details about the user from FusionAuth by calling the User endpoints.

https://fusionauth.io/docs/apis/users#response-1

@richard-0 do you have a sample repo you could share, or your full config for the SDK?

@ronn316 I believe there was an database change that was required in 1.50 https://fusionauth.io/docs/release-notes/#version-1-50-0

You will need to check the upgrade info
https://fusionauth.io/docs/operate/deploy/upgrade

specifically the database migration in silent mode
https://fusionauth.io/docs/operate/deploy/upgrade#downtime-and-database-migrations

I do this all the time and keep meaning to create a post on codingcat.dev for it instead of hitting Jeff's site for it all the time. In the meantime I would suggest checking this out it always works for me

https://fireship.io/lessons/google-apis-node-tutorial/

@evanm I would recommend using a JWT in your API and storing the user id to associate the user to your stripe user account.

You can find more about this in our tokens docs, here you will want the sub.

https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/tokens

On point two it is a classic it depends scenario. This could be handled by logic that you build, or if it makes sense you could use FusionAuth's groups or entities

@tvdlooy were you able to resolve this?

@zaalbarxx sorry for the delay. I might be missing it (sorry not a PHP person) but I don't see where that confusion comes into play. I know that some of our docs had to get updated because of a change that we made during our 1.50 release that required to request further details in our scopes request.

This release makes significant changes to the default behavior of new Applications with regard to scopes in OAuth workflows. The database migration will update existing Applications to behave in a backwards compatible manner. See the OAuth Scopes documentation for more information, in particular the Relationship, Unknown scope policy, and Scope handling policy configurations.

https://fusionauth.io/docs/release-notes/#version-1-50-0

Let me know if that still isn't making sense, or if there is a spot you were hung up on and I would be happy to update our docs. Or even better feel free to add a PR.