Heya @dan, do you have any advice on this issue?

@dan thank you so much for pointing out "user.data". I'll incorporate it into my design.

speaking of user.data - I tried using PATCH, and it works, however - when one of the fields is an array, data is constantly added to it.

{ "user": { "data": { "telegram_chat_id": 10101010101, "cameras": [ { "mac": "AA-3F-A1-00-00-00", "name": "neocam1" }, { "mac": "FF-3F-A1-00-00-00", "name": "neocam2" } ], "disarmed": 0 } } }

so after the first PATCH I've got 2 cameras, after the second PATCH I've got 4, etc.

Is this by design?

As to 'state' - I'm thinking about passing an encrypted string and decrypt it when it's back.

There is not any way to push events from FusionAuth to a system like pagerduty, except those outlined by the webhook docs which are less system level and more app level.

If you are monitoring using systems like opsgenie, you can pull data from several different sources:

There's the system status endpoint, which can be polled. Before 1.19, it was binary (200 is good, anything else is bad) but now with 1.19 there are defined status codes: https://fusionauth.io/docs/v1/tech/apis/system#system-status This is the single best endpoint for a healthcheck. If you want to ingest system logs so they can be searched/scanned, you could set up a job to export the system logs: https://fusionauth.io/docs/v1/tech/apis/system#export-system-logs and process them (that that doesn't work for container based systems, see the docs for more). These logs are what you'd see if you were running fusionauth in docker and looking at STDOUT (so system level stuff). You can write your own scripts against the API to test for certain use cases ("Can this user login?", "Can this user register?") There's an event log which captures, well, system events, which can be accessed via the API: https://fusionauth.io/docs/v1/tech/apis/event-logs There is also the audit log, which is probably not what you are looking for, because that is less system level and more 'in app' events, with admin level actions being written (see also this issue). But it can be read via API: https://fusionauth.io/docs/v1/tech/apis/audit-logs

If you are running in Fargate, k8s or another container based system, your best option is to write something to pump the logs through a stream which you can then process for interesting/problematic events.

Hiya,

Here are the VM sizes (all on AWS):

medium == t3.medium large == m5.large xlarge == m5.xlarge

These are correct as of the time I write this, but of course may change over time.

The database used is postgresql.

If you use the request body you should be fine. You can do a lot more than 500 if you like.

I would start with 5-10k and see how performance is.

@dan Yes, I am using the login API and the Identity Provided API. More specifically, the following routes: /api/login & /api/identity-provider/login. They both have similar response cookie functionality. Your explanation makes sense, however I do agree with the GitHub issue about this functionality being optional (or at least allow the developer to choose which response cookies they want to set). For the meantime, I suppose I'll just use the provided functionality as-is and look more into the mentioned alternatives if necessary.
Also, thanks for linking to the SameSite configuration. I'll take a look at it to see if it fits my needs.

Thank you for your reply!

@dan yes i can able to connect with phpmyadmin with mentioned user name but still i got the same error.

Thanks Dan. As soon as my consultant get the API for php installed I will get right on it.

Well, I'd just call the 'create registration' API from the server three times after a user had successfully registered on your custom page: https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-registration-for-an-existing-user

Does that make sense, or do I misunderstand your question?

Are you using javascript in the browser to register the user? Or a server running node (or some other language). If the latter, you could send down an HttpOnly cookie based on the response of the registration.

I'm glad you tested that your SMTP settings are correct, that's always the first place to look. It's worth noting out that there are two kinds of verification:

user email verification, which is on the user object registration verification, which is stored on the registration object

Are you trying to send a user verification or a registration verification? (It looks like registration from the email template but the user verification from the 'email verification settings' screenshot.) It might be failing because the registration template is expecting variables not set by the user verification sending.

I was able to get both email and registration verification messages using the API on 1.19.4. I just configured registration confirmation on the application -> registration tab.

What version of FusionAuth are you running? Do you see any messages in the logs?

So what I'd do is control access to the application outside of the normal FusionAuth flow.

Set up a page in your application to send people an invite. Only admin users can do so. (This solves the re-sending problem as well.)

When an invite is sent, record the timestamp and the fact that the user was invited on the user object (in the data field. Create the user, but don't register them to the fusionauth application.

When the user tries to register, it depends if you are building your own registration page or not. Given your custom needs, I'd recommend building it. In that case, you'd just see if they existed and were able to be authenticated (using the login api). After the login api returns (it'll be a 202, since they are authenticated but not authorized for the application), check to see if the timestamp is within 7 days. If so, they're registered and fine. If not, then they are presented with an error message.

As far as being able to query, if you are using elasticsearch, anything in user.data can be queried, so you could show all the users with an invited flag and a invitedTimestamp of less than 7 days. I don't have any examples of this elastic search query, but here's an example of how to run this against a registration.data field: https://fusionauth.io/docs/v1/tech/guides/advanced-registration-forms#searching-on-user-data

Does that make sense?

An alternative is to file a feature request, but I agree, the setupPassword functionality isn't quite like an invitation feature.

@fusionauth_user Seriously?! That would be awesome!

Did you end up getting it working, @tiago-cruz ?

You can also view some of the back and forth between @robotdan and I on the issue I filed: https://github.com/FusionAuth/fusionauth-issues/issues/878

Hiya,

You can purchase a support plan here: https://fusionauth.io/pricing (you'll want either 'enterprise' or 'premium' as the 'developer' plan doesn't include support).

I think the bug you are seeing around the SQL delimiter was fixed in 1.19.5, so if you want to upgrade to 1.19.x, I'd recommend upgrading to at least 1.19.5. (The bug is here: https://github.com/FusionAuth/fusionauth-issues/issues/859 but in the comments on https://github.com/FusionAuth/fusionauth-issues/issues/862 Daniel mentions removing that code.)

Yup, looks like a bug to me. I filed an issue with some more detail. Feel free to follow it there: https://github.com/FusionAuth/fusionauth-issues/issues/880

Try adding mode: 'no-cors' to your request to see if that changes your result.

Also, make sure that application/json is the Content-Type header for all requests to the FusionAuth API, unless otherwise specified in the documentation.

Narrator: This resolved the issue.