Awesome thank you so much for the help!

Per this issue https://github.com/FusionAuth/fusionauth-issues/issues/673

"This is because the services are running interactively and the logging is written to to stdout."

So when you start up your fusionauth instance using startup.bat a cmd window will open up and your logs will be written to that.

Doing so will allow FusionAuth to run even when utf8mb4 is not configured properly. We added that enforcement to ensure the limitation is understood before you turn off the enforcement.

The implication is that if you attempt to store a 4 byte unicode character the INSERT or UPDATE request will fail. The initial MySQL UTF-8 support only allowed for 3 byte characters, they then came out with utf8mb4 to support 4 byte characters.

For example, many emoji are 4 byte characters, so if you tried to store a piece of text with a smiley such as 😁 it will fail. The 😁 is a four byte character, U+1F601 or \xF0\x9F\x98\x81.

Unless you configure MySQL to use utf8mb4 any character points between U+10000 and U+10FFFF will fail to be stored.

Extracted from https://github.com/FusionAuth/fusionauth-issues/issues/234#issuecomment-632757441

Turns out that I didn't have much disk space.

Saw this in the FA search logs:

{"type": "server", "timestamp": "2020-06-10T14:34:28,378Z", "level": "WARN", "component": "o.e.c.r.a.DiskThresholdMonitor", "cluster.name": "FusionAuth", "node.name": "ubuntu-xenial", "message": "flood stage disk watermark [95%] exceeded on [NE_DhFssRru-H5oIiLwBjA][ubuntu-xenial][/usr/local/fusionauth/data/search/esv6/nodes/0] free: 887.9mb[4.4%], all indices on this node will be marked read-only", "cluster.uuid": "LGdaij30RrS4FZbgsT_6KA", "node.id": "NE_DhFssRru-H5oIiLwBjA" }

Deleting some things from my hard drive lowered my disk usage below 95% and I no longer saw the message.

@megeshg said in Authorize device without using /oauth2/device redirect:

we are not call /oauth/device would we need to? when in the flow would we need to do this? Dont see this in the documentation?

Hmmm. I think I must have been mistaken when I suggested that. I can't track down where I came up with that. My apologies.

I'm glad you found a solution.

The way most of our clients handle this is by using proxy redirect rules. For example, if your service is available at https://auth.example.com then you would redirect https://auth.example.com/ to https://example.com to push the user back into the "user" space of your site. This would mean that if you have a FusionAuth admin, they would need to directly access the UI by navigating to https://auth.example.com/admin/.

If you're already using a load balancer or a similar technology that provides routing rules, these are easy to configure.

You can also use managed IP locking (limiting access to a certain set of IP addresses), or some other type of HTTP header on the request to limit access to the FusionAuth admin UI to authorized users and treat all other traffic to anything under /admin for end users as an invalid request. These types of solutions are best handled at the network layer or with a proxy.

I totally forgot to add the register the user manually to the FusionAuth application. It is working now, thank you!

Looks like you added an issue: https://github.com/FusionAuth/fusionauth-issues/issues/668

Thanks!

@dan Thanks so much for the followup! For now, I'll work around the issue with a read/merge/write on the client.

If you are using https://aws.amazon.com/elasticsearch-service/ for your Elasticsearch server, you can access it via AWS APIs and use IAM to control access: https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-ac.html

However, FusionAuth doesn't currently support the AWS signature for Elasticsearch requests.

The recommended way of securing such clusters is to place it in a private subnet and restricting traffic to it using a security group. More information: https://fusionauth.io/docs/v1/tech/installation-guide/securing#fusionauth-search

If you have to make it public to make it accessible to resources outside if AWS you could use a source IP lock, a VPN, basic auth if AWS supports it, or you could proxy the request perhaps to another endpoint that can build the AWS sig v4 header.

The client libraries all consume the same REST API, so you can use that as a reference: https://fusionauth.io/docs/v1/tech/apis/

In order to use a custom font within a publicly accessible FusionAuth template for a hosted deployment, pull the font from a CDN or other server hosting the font.

FusionAuth doesn't have any persistent storage for custom theme assets. You can use any font you like as long as it can be included via a tag.

You can double check the client id and secret are correct and don't have any trailing white space when entered in the FusionAuth config.

The scope you have configured does not show up in the discovery document but I would assume you'd receive a different error I'd that was a problem.

Confirm you registered the correct redirect_uri (something like http://localhost:9011/oauth2/callback) in your Intuit account.

Their APIs don't seem to be working well with the client_secret_basic authentication method.

Their discovery document indicates they support both client_secret_post and client_secret_basic.

"token_endpoint_auth_methods_supported":[ "client_secret_post", "client_secret_basic" ]

The default OpenID Connect config in FusionAuth will use client_secret_basic.

I found a thread indicating others are also having problems with the Basic Authorization strategy.
https://help.developer.intuit.com/s/question/0D50f000050TBnCCAW/getting-the-errorinvalidclient-for-access-tokens

Switching the configuration to use client_secret_post seems to have allowed an authentication request.

Here's a doc about how to switch search engines: https://fusionauth.io/docs/v1/tech/tutorials/switch-search-engines

First, django-allauth supports an impressive list of providers. FusionAuth can support most of them using our generic OIDC connector, but kudos to the django-allauth team! If you are sure you only are building one django app, it's a good choice (and way better than rolling your own auth lib--please don't do that).

I'm not super familiar with django-allauth, but I did a bit of research. I think the reasons to use FusionAuth rather than django-allauth are:

centralized user management and control, even if you use a social provider. This scales to multiple applications within one tenant (so a django app and an open source forum app like nodebb can share a userbase; each user has the same username/email and password for each app) and multiple tenants (so you can have django app A and django app B totally separated, with different usernames/emails and passwords, if you're whitelabelling your app) ability to integrate with other auth providers using non OAuth protocols, like SAML FA is a single app, as opposed to a set of extensions you need to find, merge together, and keep in sync. You just drop it in and it works. additional features that you might not know you need until you need them (and have to build or evaluate/integrate a different library): passwordless consents family grouping webhooks for integration on user changes user actions groups jwt generation DAU/MAU reporting 2fa (I saw a 2fa plugin for this, but it was supported version 0.25 and django-allauth is at 0.42)

In short, FA is a full user management system, as opposed to an authentication and authorization plugin like django-allauth.

You'll need to be on version >= 1.15.0 to enable to enter the license code.

That's configurable at the tenant level.

The default is 180 seconds, but it is customizable in the tenant settings: https://fusionauth.io/docs/v1/tech/guides/passwordless#one-time-code-customization

And I can't change default port 9013 in option "fusionauth-app.https-port=9013" to 443. App just doesn't start

What error messages, if any, are you seeing in the logs when you try to start it? I was able to change the port to 4000 in a local instance and the app started. Are you starting FA using the root user, because when I changed SSL to run on 443, I saw this error:

29-May-2020 14:03:41.466 SEVERE [main] org.apache.catalina.core.StandardService.initInternal Failed to initialize connector [Connector[HTTP/1.1-443]]
...
Caused by: java.net.BindException: Permission denied

If you are seeing that in your Tomcat log files, you'll need to start tomcat as root or use a tool like jsvc to do so. Or you can just run the SSL listener on a port above 1024, like 9013.

Is there any option to use my ssl certificate to secure communication with FusionAuth app? By default its "Inversoft Self-signed root certificate Expired: Wednesday, 25 September 2013 "

You can do so by installing your own certificate in Tomcat. This is not something I've done before, but these instructions look helpful: https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html

@ashok glad you solved the problem!

The only problem is that I don't seem to be able to pass all the tokens and then "map" it out in the backend.

I'm not sure what you mean here. Are you not seeing all the tokens in the lambda? Or are you not able to put them all in the custom claim?

Also, I think I already know the answer to this and this may sound dumb, but how can you have multiple tokens? A user with multiple providers? If so, how are they consolidated and combined?

A token is tied to a registration/application, so someone could login with google to one FusionAuth application and with facebook to another. Unless I'm missing something, I don't believe they are combined.

Lastly, it would have been nice if user.registrations had a providers field.

We welcome your feature requests 🙂 . Please file a github issue: https://github.com/fusionauth/fusionauth-issues/issues

Thanks for the reply @dan.
We ended up storing sub ID on our side. We thought that might gives us more flexibility down the road (not sure about this but if it doesn't work then we'll have an extra column in the db; a small price to pay IMHO).

"Where to map the ID?" was a bit headache for us as we didn't want to miss it or make an extra call by polling ourselves. Since we are using .NET Core, we ended up hooking into OnUserInformationReceived event, one of many from OpenIdConnectEvents. Hopefully, I'm not doing something really stupid.