OpenSearch version 2.x will function properly with FusionAuth version >= 1.42.0.

Related GH Issue: https://github.com/FusionAuth/fusionauth-issues/issues/1558

If you run into issues please let us know or file an issue so we can take a look.

You have a couple of options:

you can update webhook so it always returns 200, regardless of the message it receives. This won't work if the webhook URL is incorrect. For example, if you set up the webhook to live at https://exmple.com when it really lives at https://example.com and you don't have access to https://exmple.com. if you have an API key, you can update the webhook to be non-transactional. Setting up such an API key is a critical part of common configuration. if someone has an active session in the admin UI, they can also modify the configuration to make the webhook non-transactional.

We have the exact same issue. If this was solved (hopefully) could you please provide a brief description on the fix?
Thanks!

@ryan-1 Great question. This is an implementation detail so isn't documented.

While you can definitely test this out, it may change in the future.

Can you help me understand your use case? Maybe there's a different way to achieve what you are trying to do.

@cody Thank you for sharing!

You have to break apart the bcrypt hash. More documentation available here: https://fusionauth.io/docs/v1/tech/apis/users#password-hashes

Let us know if that helps, please.

@dan thank you

Hi @lou,

I was unable to replicate this issue. I'm using 1.47.1.

I used the login API for simplicity. I set up an application to Generate Refresh Tokens and Enable JWT refresh on the Security tag.

I set up that application up with three roles, and a group with one of those roles. I then assigned a user to that group.

I called the Login API and got back a refresh token as well as an access token. I examined the access token and saw the expected one role.

I then added another role to group. Then I called the /api/jwt/refresh endpoint and looked at the resulting access token. That access token had 2 roles now.

Here are the two requests:

curl -H 'Authorization: bf69486b-4733-4470-a592-f1bfce7af580' http://localhost:9011/api/login -d '{"applicationId":"85a03867-dccf-4882-adde-1a79aeec50df","loginId":"admin@example.com","password":"password"}' -H 'Content-type: application/json' curl -H 'Authorization: bf69486b-4733-4470-a592-f1bfce7af580' http://localhost:9011/api/jwt/refresh -d '{"refreshToken": "fYFIudBHGFJMsBrmufiTJjvczKYkq6BvNTn3B6oIKRvXn4mJd4NQdA"}' -H 'Content-type: application/json'

A few more questions to see if we can track down this behavior:

What version of FusionAuth are you running? Can you provide more detailed recreate steps? Did you use the authorization code grant? Did you do something else between the initial login and the token refresh? How did you update the group role setting? How many nodes of FusionAuth are you running?

Thanks,
Dan

Hi @sandesh,

You should follow the steps outlined there and set up your headers.

There's more in the proxy configuration guide:

https://fusionauth.io/docs/v1/tech/admin-guide/proxy-setup

Hope that helps.

Hi @clowen !

What version of FusionAuth are you using?

Have you set up a lambda function for this application?

Are you providing the applicationId on the request? Better yet, can you please provide the request you are making?

Hi @pedroparente ,

If you can't make a workflow work for your use case, the usual suggestion is to drop down to using the APIs.

In this case, you could build your own page which let users change their password and use the User Update API to directly change their password.

Of course, that's more work and circumvents the security posture that FusionAuth provides.

There's no way to do this within the hosted login pages currently, but you are welcome to file an issue explaining your use case.

Hiya @alexiussamson83 ,

The recommended way to import users into FusionAuth, including password hashes, is to use the User Import API.

Modifying the database directly is not supported.

Hiya @kamalesh-d,

Welcome to FusionAuth!

This looks like it should work. Are you seeing any errors in the console?

Hi @john-bantoto,

Welcome to FusionAuth!

Are you using this lockout configuration?

In that case, the answer to your question is:

it is a time based solution. The time period is "The window of time in seconds for which the failed authentication attempts are counted. If no further failed attempts occur the failure count will be reset after this time period starting at the time of the last failed login." it does not get reset on successful login. Once the action is applied, it will remain applied for its configured duration (15 min in your case).

Hope this helps.

@stephan I have an idea, but not 100% sure it would work. It still involves using a lambda but you would not need to use the HTTP Connect function of the lambda to call the API so I think it will still work in that respect. Maybe this will help you come up with an even better idea. Here is the gist.

User logs in and is Authenticated

On your application server, use the FusionAuth APIs to push the user IP address to the user.data in FusionAuth

Create a Populate JWT lambda that pulls in the user data, specifically the ip address

refresh the token

once the token is refreshed test for the IP address

The part I am not 100% sure on is if the refresh token will add the new Data. I think it will, but you will have to test it out.

Also, I think I may have read your initial question wrong, I am not super clear on the "JWT token comes from the IP that it was issued to". Do you mean you need the users IP or the IP of the machine that issues the JWT (FusionAuth server)? My assumption was the users IP.

If it is the FusionAuth server, you could do something like create a little service that pings the FusionAuth server address and updates all the users user.data with the address and then create the JWT Populate lambda to pull that info.

Also, if you need the address of the FusionAuth server and it does not change, you could just hard code that into the JWT Populate lambda. Of course, if the IP address every changes, your users will see the wrong address until you update.

In any case here are some links on how to populate user data in with the JWT Populate lambda.

https://fusionauth.io/docs/v1/tech/lambdas/jwt-populate

https://fusionauth.io/blog/sharing-custom-oauth-claims-with-a-asp-netcore-app

I don't think any of these are great solutions, but may provide a workaround for what you need.

Please let me know if this helps.

@pedroparente You may try need to update the version of FusionAuth. Seems like it could be related to this issue. https://github.com/FusionAuth/fusionauth-issues/issues/1909 which was fixed in 1.43.0.

FUSIONAUTH_APP_HTTPS_CERTIFICATE would be the variable name to use.

However, properly escaping a multi-line certificate can be tricky.

If you can write the cert out to a file, you could set FUSIONAUTH_HTTPS_CERTIFICATE_FILE instead, which doesn't have the escaping complexity.

@anthony-hollingsworth apologies, but I have been away from the forum for a while. Thanks for following up and am glad you found a solution. Thanks for sharing.

The hosted backend will check the Origin or Referer header on the request and validate that it comes from an origin that matches the domain of the host of the request to FusionAuth. If they do not then we return a 403 regardless of what the CORS configuration is set to.

Ideally to get this to work with the remote instance you may want to try setting a local proxy with "local.fusionauth.io" or similar set to localhost:4000 so that the browser sees this as the same apex domain as FusionAuth.

Utilizing a different port instead of route based paths tends to work better.

Below is an example using express / http-proxy-middleware.

const express = require("express"); const { createProxyMiddleware } = require("http-proxy-middleware"); const app = express(); app.use( "/", createProxyMiddleware({ target: [FUSION_AUTH_HOST_HERE], // example: https://example.fusionauth.io changeOrigin: true, headers: { "X-Forwarded-Proto": "http", "X-Forwarded-Host": "localhost:4001", "X-Forwarded-Port": "4001", "X-Forwarded-Server": "localhost:4001", }, }) ); app.listen(4001);