@netstack said in Setting fusionauth-app.http.cookie-same-site-policy to none in Version 1.4x:
It does look like the fusionauth-app.http.cookie-same-site-policy has been deprecated as of ver 1.37.0 and I do not know of another way to set it. As browsers are moving away from 3rd party cookies, I think this makes sense.
@dan Thanks a lot for sharing a fantastic piece of content in detail. In my opinion, WebAuthn also represents a significant leap forward in online security and user authentication. By leveraging public key cryptography, supporting various authentication methods, and promoting a passwordless approach, it not only enhances the protection of user accounts but also streamlines the authentication process for a more user-friendly experience.
Thanks
There are a few options.
- the admin UI application is in the default tenant and can't be moved, so add all other users to a new tenant. This adds an additional layer of separation
- use the IP ACLs function if you are on the enterprise plan
- use a proxy and have the proxy filter out traffic that doesn't originate from the office network and is requesting anything with the FusionAuth admin UI client id (which is immutable)
I've come across the same issue. FusionAuth and my webhook endpoint are both on the same network (docker compose). I've tried setting the webhook URL to the container name (invoicing.api) with the corresponding port, https://invoicing.api:5001. The call never reaches my api. Testing through Postman or Swagger which are running on the same machine but outside the docker network works fine using https://localhost:5001/fusionauthwebhook.
I came across a similar issue with FusionAuth and my web app authority URL not working when using the container name in the URL, but this was solved by using the local machine IP in it's place. That doesn't seem to work for webhooks. Using the local machine IP in the webhook URL, i.e. https://192.168.0.110:5001/fusionauthwebhook, didn't solve it.
@mark-robustelli
I have studied this further, I was using a small s instead of a capital S in the line
"php -S localhost:9012 -t public".
With that change I was able to get the server running with a steam of code as below.
The stream stopped on the last line with the cursor flashing for 1 hour. I finally shut it down.
The web site comes up with the coin picture but clicking on the LogIn button generates an error message.
I don't think this is ready for prime time in Windows 11.
@dan Sorry I think I lost the notification about your reply somewhere.
Basically, it seems like the issue is there is data you send during the login which you want stored in user.data. You can do this with the user create API but not with the idp login API call.
Almost, it's not during login but during registration, just with idp it's a login call that can result in registration.
I think being able to solve this would solve the issue.
The suggestions you gave are not very atomic. We have many users with spotty network connections, so we're trying to stick here with 1 API call for registrations.
@dan The community edition is self hosted on a MacPro on the Docker container.
The debug is enabled.
The message I received immediately on 'Send test email' is:
On Event log there is nothing relating this error.
FusionAuth version is:
