Best posts made by dan

user-data

I'd like to update the user data object in the UI. I know I can do it via the API: https://fusionauth.io/docs/v1/tech/apis/users

dan

https://fusionauth.io/blog/2021/04/01/fusionauth-introduces-simplepass/

dan

I have a quick question about FusionAuth and configuring the inactivity timeout of the session cookie it creates. Specifically... Is it possible?

dan

Can you run FusionAuth in Kubernetes?

dan

Is modifying the JWT via a lambda equivalent to accessing the verified property of the user profile?

Within a lambda, you have access to the user and registration properties. So you'd pull the verified property from wherever you wanted and put it into the JWT as a custom claim. Here's a blog post about how that might work.

So yes, it is the same data. It's the tradeoff between a bigger JWT and having to make the additional call from your API.

Don't forget that the JWT will live for a while, so if this sequence happens and you use the JWT, you might have a user with a verified email prevented from using the API.

user registers
JWT issued, with verified set to false because the user isn't verified.
User verifies their email
User visits API, but is denied because the JWT has stale data.

I don't know timelines and how long your JWTs live for, but this is something to consider. Does that answer your question?

dan

OK, we just released 1.18.8 and that is the version you want to use:

In requirements.txt:

fusionauth-client==1.18.8

And then this is the call you want to make (with client_id before redirect_uri) :

 resp = client.exchange_o_auth_code_for_access_token(request.args.get("code"), client_id, "http://localhost:5000/oauth-callback", client_secret)

dan

Hiya,

First off, we'd recommend having all the flow you outline be over TLS. That's good enough for most major ecommerce systems and so shouldn't be insecure. If you aren't serving your application over TLS, then I'd advise doing so. And note that the flow is actually:

My Frontend --> My Backend --> FusionAuth API

There's no password returned from the registration API call.

If you are concerned about a new user's password being insecurely transmitted through your application, you could use the FusionAuth hosted login pages and theme them to be like your application. (More docs.)

The other option, which takes encrypted passwords, is the Import Users API, but that's probably not a fit for one off registrations. There are no plans to accept encrypted passwords for one off user registrations. Here's a related issue you can weigh in on/vote up if you'd like. Or feel free to open a new issue if that one doesn't capture the essence of your idea.

Are there specific security concerns you have around your front end/back end systems that I might be missing?

dan

I haven't seen that before.

Does this happen in your customized version of FusionAuth (where you've added a few applications and users) or the default version?

From looking at the mysqldump man page, maybe try --hex-blob ?

You could try loading the schema from the .sql files ( https://fusionauth.io/direct-download/ ) and loading the data separately (that is, exporting with --no-create-info ). Again, that's a wild guess, not sure what the issue is, but some more investigation seems to make sense.

dan

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/

dan

Ah, the answer is that Nginx defaults to HTTP/1.0 and if you are on a recent version of FusionAuth, this protocol is not supported by our HTTP server (HTTP 1.1 was, after all, released in 1997 ).

The remedy is to update your Nginx configuration to use a later protocol with this change:

proxy_http_version 1.1;

Hope that helps.

dan

@mweiss 1.26 was released today. You can read the release notes here: https://fusionauth.io/docs/v1/tech/release-notes/#version-1-26-0

It is available on dockerhub and the download page.

dan

Thank you for writing it, I thought it was a great piece!

user-api

Hiya,

I'm unable to create a user registration using the .NET client libraries: https://fusionauth.io/docs/v1/tech/client-libraries/netcore

I have verified that the API key is basically a super user. I've verified that I'm sending the registration object. I've tried twiddling different properties (verified, insertInstant) and made sure that the application exists. I've added the a user registration to the application manually and it works. Creating a user and setting the userdata works just fine. It just seems like the registration isn't working.

I looked in https://github.com/FusionAuth/fusionauth-netcore-client/issues and https://github.com/FusionAuth/fusionauth-issues/issues but didn't see any relevant issues.

Here's my code so far (you can run it with fusionauth_api_key=<key> dotnet.exe run -- foo@foo5.com bluepass123 blue)

$ cat usermanager.csproj
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="FusionAuth.Client" Version="1.15.7" />
    <PackageReference Include="JSON.Net" Version="1.0.18" />
  </ItemGroup>

</Project>

$ cat Program.cs
using System;
using io.fusionauth;
using io.fusionauth.domain;
using io.fusionauth.domain.api;
using System.Collections.Generic;
using Newtonsoft.Json;

namespace usermanager
{
    class Program
    {
        private static readonly string apiKey = Environment.GetEnvironmentVariable("fusionauth_api_key");
        private static readonly string fusionauthURL = "http://localhost:9011";

        private static readonly string tenantId = "66636432-3932-3836-6630-656464383862";
        static void Main(string[] args)
        {
            if (args.Length != 3) {
                Console.WriteLine("Please provide email, password and favorite color.");
                Environment.Exit(1);
            }
            string email= args[0];
            string password = args[1];
            string favoriteColor = args[2];

            FusionAuthSyncClient client = new FusionAuthSyncClient(apiKey, fusionauthURL, tenantId);
            User userToCreate = new User();
            userToCreate.email = email;
            userToCreate.password = password;
            Dictionary<string, object> data = new Dictionary<string, object>();
            data.Add("favoriteColor", favoriteColor);
            userToCreate.data = data;
            UserRegistration registration = new UserRegistration();
            registration.applicationId = Guid.Parse("4243b56f-0b45-4882-aa23-ac75eea22d22");
            registration.verified = true;

            registration.insertInstant = DateTimeOffset.UtcNow;
            var registrations = new List<UserRegistration>();
            registrations.Add(registration);

            userToCreate.registrations = registrations;

            UserRequest userRequest = new UserRequest();
            userRequest.sendSetPasswordEmail = false;
            userRequest.user = userToCreate;
            string u = JsonConvert.SerializeObject(userRequest);
            Console.WriteLine(u);
            var response = client.CreateUser(null, userRequest);
            string json = JsonConvert.SerializeObject(response);
            Console.WriteLine(json);

            if (response.WasSuccessful())
            {
                var user = response.successResponse.user;
                Console.WriteLine("retrieved user with email: "+user.email);
            }
            else if (response.statusCode != 200)
            {
                var statusCode = response.statusCode;
                Console.WriteLine("failed with status "+statusCode);
            }
        }
    }
}

dan

There's now an open source terraform provider available: https://github.com/gpsinsight/terraform-provider-fusionauth

It's also on the registry: https://registry.terraform.io/providers/gpsinsight/fusionauth/latest

dan

https://fusionauth.io/blog/2021/04/08/why-user-multi-factor-authentication/

dan

Well, since we're talking about behavior based on a fix that isn't written yet, things are a bit theoretical.

Here's one approach we'd consider. An expired key pair cannot be used to sign a JWT, so we would either have to generate a new key pair ahead of the expiration, or start failing login operations. The former is a better user experience, so a user will either have to regenerate the key, or we would do it based upon a configured policy.

Also, wanted to be clear that we are aware of this limitation, which is why we set the default expiration period to 10 years (so we have a bit of time to solve this in the best way possible).

Hope this helps. Let me know if you don't have the information you need.

dan

You can read the release notes here: https://fusionauth.io/docs/v1/tech/release-notes/#version-1-26-0
You can read a blog post here: https://fusionauth.io/blog/2021/05/03/announcing-fusionauth-1-26/

dan

A conversation with @a-abbas: https://fusionauth.io/blog/2021/04/13/oggeh-fusionauth-gluu/

An excerpt:

OGGEH Cloud Computing is the only qualified Progressive Web Application (PWA) Agency by Google Developers in Africa and the MENA region. As well as the only Google Cloud Technology Partner in the Arabian countries! Actual users/customers are always looking for a simple way to manage their content at the backend. Something that does not involve writing mysterious markup like HTML and/or weird shortcodes as most plugins do (for WordPress, Joomla, Drupal, and others).

OGGEH Cloud Platform takes care of complex backend/infrastructure logic for security and scalability.

dan

Hiya, no worries!

As mentioned in this github comment, we don't support continually renewing refresh tokens, as that essentially means that users remain logged in forever.

We do not currently issue a new refresh token during the refresh_token grant. If the refresh token you sent is valid you'll get a new access_token back. Once your refresh token expires, you'll need to request a new one by requiring the user to authenticate again.
If we were to issue a new - or "refreshed" (updated expiration) each time you used the refresh token to gain a new access token using the refresh_token grant - that would effectively provide a sliding window session. This would allow for a perpetual use token which we do not support.

Totally understand your UX concerns. There's a tension between ease of use and security that only you can balance.

I don't know the application or data you're working with, so I can't make firm recommendations. However, you can set the refresh token to have a long lifetime like 180 days. That is a setting in the tenant screen or tenant.jwtConfiguration.refreshTokenTimeToLiveInMinutes in the API. And then have the user log in after the refresh token has expired.

Please feel free to file an issue in the GitHub repo explaining the use case for perpetual use tokens. We can't commit to any implementation but we love to hear what customers want, and GitHub is what our engineering team uses to feed the development backlog.

dan

Release notes: https://fusionauth.io/docs/v1/tech/release-notes#version-1-37-0

Blog post: https://fusionauth.io/blog/2022/08/10/announcing-fusionauth-1-37