Hey folks,

Coming from the future. I just decided to change my docker-compose.yml to use network_mode: host therefore my former comment is no longer valid. Please look at my monorepo on how I am utilizing Terraform, Docker, mailcatcher as my local SMTP, NestJS, and NextJS.

I also wrote a couple of README.mds here and there for future references.

Feel free to give it a star on GitHub and or better yet use it.

@egli said in Upgrading from 1.46.0 to 1.47.1 CSRF token issue with IdP:

Similar issue and was able to resolve it by following changes mentioned here:
https://fusionauth.io/docs/release-notes/#version-1-47-0 slice master

Can you explain in more detail?

@sandiprghane based on that info, I think the above method will work for you and as I mentioned, maybe check out custom scopes for third party applications if you have a license that supports it.

Hello @cristian
I am kind if facing the same issue here, how did you go about solving it?

Well, since we're talking about behavior based on a fix that isn't written yet, things are a bit theoretical. 🙂

Here's one approach we'd consider. An expired key pair cannot be used to sign a JWT, so we would either have to generate a new key pair ahead of the expiration, or start failing login operations. The former is a better user experience, so a user will either have to regenerate the key, or we would do it based upon a configured policy.

Also, wanted to be clear that we are aware of this limitation, which is why we set the default expiration period to 10 years (so we have a bit of time to solve this in the best way possible).

Hope this helps. Let me know if you don't have the information you need.

As of q4 2021, FusionAuth officially supports Kubernetes.

You can read the docs here: https://fusionauth.io/docs/v1/tech/installation-guide/kubernetes/

@dan 160ms

Another option that works as of today is to set up a tenant to tenant connector.

Add a connector to the new tenant. Point it at the /api/login endpoint of the old tenant, including an API key as a header.

Change your app to send everyone to a new application in the new tenant.

When the user logs in to the new application, if it is the first time they've been seen, the old tenant data, including password, will be queried. The password hash will be transparently migrated to the new tenant.

This slow migration takes time, but is another option.

I'm starting to think I may misunderstand what this complete login endpoint objective is.

I think I'm the one who is misunderstanding things 🙂 Yes, you should be able to build your own login pages to auth directly with google, and yes, you should get the refresh_token returned. I didn't follow what you were attempting to do, I thought you were using the google form provided by FusionAuth (which is what I tested and which returns a refresh_token if you provide the scope).

This sure looks like a bug because the refresh_token should be returned according to the docs. At the very least it is a doc bug, because the noJWT parameter doesn't state that the refreshToken will be returned if noJWT = false:

When this value is set to true a JWT will not be issued as part of this request. The response body will not contain the token field, and the access_token and refresh_token cookies will not be written to the HTTP response

But the response body states a refreshToken will be returned:

The refresh token that can be used to obtain a new access token once the provide one has expired. Because a refresh token is per user and per application, this value will only be returned when an applicationId was provided on the login request.

Can you please file a bug? https://github.com/fusionauth/fusionauth-issues/issues

Looks like this might be an issue you'd want to upvote: https://github.com/FusionAuth/fusionauth-issues/issues/439

Thanks for the information keep sharing such informative post keep suggesting such post.

this section for localhost

server {

listen 80;

server_name YOURSITENAME.COM;

location / { proxy_pass http://127.0.0.1:9011; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; }

}
#######################################################################

this section for https (ssl)
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name YOURSITENAME.COM;

location / { proxy_pass http://127.0.0.1:9011; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; }

}

Great. I've updated the documentation to reflect that google and facebook aren't supported; that'll be published next week. Sorry about that.

More details on the bug I filed above (and the doc change linked in the bug). If you try this with SAML/OIDC and it fails, please let me know.

Works perfectly. Much appreciated!

Hi @daniel-barrett ,

Sorry for the hassle!

All the hosted login pages that FusionAuth makes available are documented in the themes section.

That Integration Points doc is pretty new, but if you haven't seen it is worth a read. Would love any feedback on that.

Ah, great. Yes, if you are running both the database and FusionAuth, you need more memory. If you are running elasticsearch too, you'll need even more.

@pleymor said in CORS error when posting to /oauth2/token:

Access to XMLHttpRequest at ... has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

The Same Origin Policy (SOP) is a security measure standardized among browsers. It is needed to prevent Cross-Site Request Forgery (CSRF). The "Origin" mostly refers to a "Domain". Same Origin Policy prevents different origins (domains) from interacting with each other, to prevent attacks such as CSRF (Cross Site Request Forgery) through such requests, like AJAX. In other words, the browser would not allow any site to make a request to any other site. Without Same Origin Policy , any web page would be able to access the DOM of other pages.

This SOP (Same Origin Policy) exists because it is too easy to inject a link to a javascript file that is on a different domain. This is actually a security risk ; you really only want code that comes from the site you are on to execute and not just any code that is out there.

If you want to bypass that restriction when fetching the contents with fetch API or XMLHttpRequest in javascript, you can use a proxy server so that it sets the header Access-Control-Allow-Origin to *.

If you need to enable CORS on the server in case of localhost, you need to have the following on request header.

Access-Control-Allow-Origin: http://localhost:9999

@orrett

You are welcome! Hope it goes well!

@michael-schramm can I reach you somewhere for a short discussion? Am also thinking about going for CockroachDB and have a couple questions. 😅

@fred-fred said in Is there an example of how to authorize a user to an app and allow them to access after using the login API?:

May I ask, why do you have /API/Login if all it really does is authenticate but not authenticate and authorize like the Login pages?

I'm not sure I totally understand the premise of the question. I hear your frustration, however.

The Login API provides a JWT, which can be used for authorization. It seems like you are looking for configurable SSO which is, as I understand it, a different thing.

Our SSO implementation (like almost every other SSO implementation for web browsers) depends on cookies, which are not really something you can set with a backend API in a effective way (because the cookies have to be set by the component responding the browser, which the Login API will not be.) If there's an SSO implementation that is available via an API, please share that as we're always looking to improve.

When you use the Login API, you have complete custom control over every aspect of the UX. But with great power comes great responsibility 🙂 , and part of that responsibility is re-implementing SSO.