I end up using a docker image of mailcatcher.

I use the default docker-compose.yml, but use this docker-compose.override.yml:

version: '3' services: mailcatcher: image: yappabe/mailcatcher ports: - "1025:1025" - "1080:1080" networks: - mailcatcher search: image: docker.elastic.co/elasticsearch/elasticsearch:7.8.1 environment: cluster.name: fusionauth bootstrap.memory_lock: "true" discovery.type: single-node FUSIONAUTH_SEARCH_MEMORY: ${FUSIONAUTH_SEARCH_MEMORY} ES_JAVA_OPTS: ${ES_JAVA_OPTS} # Un-comment to access the search service directly # ports: # - 9200:9200 # - 9300:9300 networks: - search restart: unless-stopped ulimits: memlock: soft: -1 hard: -1 volumes: - es_data:/usr/share/elasticsearch/data fusionauth: depends_on: - search - mailcatcher environment: SEARCH_SERVERS: http://search:9200 SEARCH_TYPE: elasticsearch networks: - mailcatcher - search networks: search: driver: bridge mailcatcher: driver: bridge volumes: es_data:

Then I configure the SMTP settings to use the hostname mailcatcher and the port 1025. I can then send email and view it in the mailcatcher interface, at localhost:1080.

Here's the relevant dockerfile: https://github.com/yappabe/docker-mailcatcher/blob/master/Dockerfile

Here's more about mailcatcher: https://mailcatcher.me/

The user and registration may have a username field. The username field on the user is the one that can be used to login. In general you will want to use the Search API for those types of queries rather than directly accessing the database.

The reason is because the API is documented and stable, and the database is undocumented and may change.

Hi @luke-fishman,

I have a few questions for you to see if we can get to the bottom of this.

Is this an ongoing problem or has it recently surfaced? If recently surfaced, has anything changed which would slow your queries down? For instance, have you made any architecture changes? Was this user query much faster in the recent past?

What do queries from the Admin UI look like (are they performant?)?

Other things to evaluate include the size of your database and your architecture to make sure it's right-sized for your use case.

Finally, are you seeing anything in the error and event logs in FusionAuth (or in your server) that would indicate a larger problem?

Thanks,
Josh

You will need to obtain the default tenantId from the UI.

If you are using kickstart, you have the option to set the default tenantId so that it is predictable.

Thanks for filing a github issue as well!

https://github.com/FusionAuth/fusionauth-issues/issues/1227

Hi @tl-fa,

You can view our Roadmap Guidance regarding how features are implemented into FusionAuth. A good snapshot of current development can be found here as well.

We will certainly update any related issue cards as development moves forward!

Thanks!
Josh

@maarten,

Glad that you got this working! If you have any other tips about how you got it working, that might help other users in a similar situation.

Glad it worked out!

Thanks,
Josh

A duplicate of https://fusionauth.io/community/forum/topic/438/password-complexity-rules

But the easiest way to see this is in the tenant API, since that is where they are configured.

At time of writing, here are the options.

Screen Shot 2021-05-12 at 1.50.12 PM.png

Awesome, glad to help.

Just to be transparent, application theming requires a paid edition license. You can buy one here: https://fusionauth.io/pricing/editions/

Here was some feedback from other users:

I have a k8s cron job that queries the FA eventLog API and sends them as DataDog events, then depending on severity a DataDog Event monitor will fire. Other than that, I feel rather blind.

we havent been able to upgrade quite yet, but 1.26 added a prometheus endpoint
right now we use the datadog jmx integration to get some stats, and we also do things like http monitoring

Here's the prometheus endpoint docs: https://fusionauth.io/docs/v1/tech/tutorials/prometheus/

It looks as though Trend Micro (or whatever security solution is being used as a pass through) is modifying the URL and not properly preserving the URL encoding. You will need to inquire with Trend Micro about why this would be occurring.

Interesting, not sure how this would happen. Thanks for the report @stuart-auld - I agree, this is not a good dev experience. We will identify this cause and try to failure better.

Tracking via GitHub Issue #1217

An update! The client credentials grant is now available in paid editions of FusionAuth.

Here is the documentation:

https://fusionauth.io/docs/v1/tech/oauth/#configure-entities

https://fusionauth.io/docs/v1/tech/oauth/#example-client-credentials-grant

Did you ever find a solution @developer ?

For the first issue, did you turn off client authentication in the FusionAuth application OAuth tab?

And now it works fine with 152 threads connected, so unable to reproduce this.

I'll keep an eye out for this behavior and file an issue if it pops up again.

For the record:

FusionAuth 1.27
installed via zip file
Mysql 8.0.23 installed/managed via homebrew on the mac.

We were working on getting it documented and it shipped yesterday. Sorry for the delay!

https://fusionauth.io/docs/v1/tech/apis/entity-management/ outlines all the relevant APIs, including entity CRUD.

You might also be interested in the client credentials grant, one of the main use cases:

configuring entities for the client credentials grant: https://fusionauth.io/docs/v1/tech/oauth/#configure-entities an example client credentials grant: https://fusionauth.io/docs/v1/tech/oauth/#example-client-credentials-grant

@Moonshine,

Glad you found it in our UI!

Thanks,
Josh

No, it is more like terminating an EC2 instance. All data is lost.

If you have user data you'd like to retain, please request a database dump before destroying your deployment.