Thanks for the info Dan.

Zendesk also support JWT/oAuth SSO. I guess I'll give that a try - though it seems unlikely to give a different result.

If that fails, we will rely on session timeout and disable the logout button.

@elliotdickison,

What you are looking for is some of the Auth Flows that we have outlined (pay attention to the recommended ones for a secure setup). Specifically, this one might be helpful.

The common pattern is to have a BFF (backend for frontend) to keep things secure.

We have a nice example of how to securely complete the OAuth handshake in our 5-minute guide, with a section on how to use cookies. I would start there for an overview on how to complete the OAuth handshake using express and nodeJS.
https://fusionauth.io/docs/v1/tech/5-minute-setup-guide#cookies-for-a-single-page-application

I hope this is a good starting point. Let us know if you have other questions.

Thanks,
Josh

@sohwh,

You can find our system requirements for the database listed below:

https://fusionauth.io/docs/v1/tech/installation-guide/system-requirements#database

FusionAuth should run all major Linux operating systems as documented below

https://fusionauth.io/docs/v1/tech/installation-guide/system-requirements#operating-system

I hope this helps!

Thanks,
Josh

I have added a further suggestion to the issue on the app repo.

https://github.com/FusionAuth/fusionauth-issues/issues/1250#issuecomment-859634082

@faizan

I'm not sure what you are asking for, but have found swaks to be a good tool for testing SMTP functionality from the command line.

Here's the swaks website/docs: http://www.jetmore.org/john/code/swaks/

Does that help?

As answered on https://github.com/FusionAuth/fusionauth-issues/issues/1263, this was indeed an issue with port 25.

For anybody encountering the same problem:

Try switching to another port (587, 465, or 2525) Try switching TLS to SSL and the other way around with all the different port configurations.

Took me a while to find this, probably because I mistyped 587 as 578.

In the meantime we could implemented it with the mentioned workaround.
Late thanks @robotdan !

@alessandrojcm,

Sounds good. I have logged a bug report; we should have this one squashed soon!

Thanks,
Josh

For anybody having this issue, it turned out I had written my URL wrong: http://company.fusionauth.io for example instead of https://company.fusionauth.io. The redirect to https:// caused the error.

We understand that sometimes you want to "kick the tires" to ensure that a feature will work for you, especially if you are going to pay for it.

You have two main options.

The first, which gives you the most flexibility, is to do the following:

Install the FusionAuth community edition somewhere (see the installation guide for all the options) Sign up for a developer license trial. This will require you to enter your credit card, but it will not be charged for the length of the trial (2 weeks at the time I write this). Follow the directions on the reactor page to install the license and activate the features. Cancel the trial at the end of the two weeks or before, if the features don't meet your needs. (We'd love feedback on how they didn't meet your needs, too! Please file issues to help us improve.)

The second option, which requires a lot less work but will give you less control, is to use the sandbox site. This lives at https://sandbox.fusionauth.io/ . With this option, you don't need to enter your credit card, sign up for an account or remember to cancel. This instance has a valid developer license, allowing access to all the premium features.

However, there are limitations:

Any information you enter is public and can be viewed by anyone else looking at the sandbox at the same time The sandbox environment is reset regularly to a known state, so your changes will be wiped at that time.

@spfarran

Glad you got it figured out!

Thanks,
Josh

I'm a former consultant, so the answer is, as always, "it depends".

Strengths of running in different tenants:

easier to manage (only one instance to run and upgrade) configuration, such as lambda or identity provider config, can be shared across tenants cheaper to run (again, only one instance and database to pay for)

Strengths of running in different instances:

true isolation when running you can allow developers access to the admin ui of the instance a misconfiguration in development isn't going to affect production you can have a true IaC approach, where you deploy config changes across environments one at a time

In general, it makes sense to be careful about production environments, as if any configuration changes are made in error, it can impact the customer experience.

It really depends on what works best for you.

@twilkinson,

Hello again!

Yes, this is how I read that as well from the documentation. You could also test that logout is enforcing the behavior that you are seeking by using the browser console to check for cookies. Or if not storing the token in cookies, checking the relevant location and/or behavior to ensure that the user's refresh/access tokens are properly removed/invalidated.

Based on the documentation, you should provide the refreshToken in the request to invalidate, as seen below:

6805586d-d207-4358-b4a1-97b62b5e0453-image.png

Thanks,
Josh

 

Related Links

https://fusionauth.io/community/forum/topic/270/logout-questions/5

There is no out of the box solution for this. See https://github.com/FusionAuth/fusionauth-issues/issues/763 for the tracking issue.

However you can still do this with the API.

If you are consuming a JWT, you can see if a user has enabled two factor authentication by putting a claim in the JWT using a populate lambda. Look at the user object and if the twoFactor.methods array isn't empty, they have enabled MFA. If you are not using a JWT but instead examining the user object directly, you can look at the same attributes.

In each case, you should set up a page to allow the user to enable MFA and keep directing them there until they have done so. You can either build your own 'MFA enable' page or, if you have a paid edition, use the themeable account self service pages, as documented here: https://fusionauth.io/docs/v1/tech/account-management/

I think we can close this one as we are picking it up in https://fusionauth.io/community/forum/topic/1011/fusionauth-nextauth-refresh-tokens/5

Hey If you are running on a VM in AWS its important to do a few things,

Best would be to set up a webserver or loadbalancer to proxy and do SSL termination to your fusionauth instance.

The webserver would run on port 80 and 443, All non SSL requests would need to be redirected to 443. Then you let the webserver proxy and forward all headers to your fusionauth instance on the port where you have fusionauth running.

As for development mode, you can set this with an environment variable on the server check https://fusionauth.io/docs/v1/tech/installation-guide/fusionauth-app/ out for more info on this.

Hope it helps and cheers!

@dan said in Shopify integration:

Hmmm. That's a bummer that Shopify isn't being responsive. Here's what I have found:

Can Shopify Plus acts as an Identity Service provider (physically store the users without using 3r party ISP) and allow other applications (including ours) to authenticate via SAML?

Yes, documented here: https://help.shopify.com/en/manual/shopify-plus/security/saml

This looks like this only works with Shopify users who are in your organization. (Employee time tracking, not time recording.)

Can Shopify (Plus or Non-Plus) authenticate users using Shopify accounts.

I don't know. This https://shopify.dev/tutorials/authenticate-with-oauth sure looks like a OIDC flow, but I'm not sure how it works without setting it up. Have you tried to set up an OIDC identity provider? That's what I'd do.

Dan, You right
It`s works without setting it up, Thank You