Group Details Private

Power User

Helpful folks who know a lot about FusionAuth

  • RE: Access google calendars of multiple google accounts (with user permission)

    Sure!

    This is a case of Third-Party Service Authorization where your application is trying to access data on behalf of users held by another party (Google in this case).

    This will require some integration work on your part, but the basic steps are:

    • Integrate your application with FusionAuth (our quickstarts are a good place to start). Make sure you check the 'keep me signed in' value set, using a hidden field.
    • Set up an Identity Provider. You don't want to use the Google Identity Provider because it doesn't support the prompt URL parameter.
      • Use the OIDC Identity Provider with the prompt parameter set to select_account to let the users pick different accounts, and make sure you set access_type to offline to get a refresh token. More here.
      • Set the Linking strategy to Pending.
      • You'll also need to set up your Google scopes correctly. Based on your question, you'll want to use https://www.googleapis.com/auth/calendar.events.readonly as an additional scope.
      • You'll want to follow the Google Identity Provider instructions insofar as they pertain to navigating the Google Cloud Console.
    • Create an 'connect your account with google' button in your application. This should point to the OIDC Identity Provider. You can use an idp_hint to send the user directly to Google when they click it.
    • After they return from google, having selected their account, they should be logged in to your application. (It's possible with Pending they'll be prompted to login to your application again, but I don't think so. Would have to test.) They'll also have a link that is accessible via the Link API. That link will contain the refresh token in the token field.
      • You can also iterate all the links in your application using one of our client libraries to display to the user which google accounts they have connected.

    Now you have connected 1 or more Google accounts to a FusionAuth account.

    Next, when you want to retrieve calendar events for your application to process, take these steps:

    • Call the Links API for the user to retrieve all the links
    • Retrieve the Google refresh token from the token field
    • Get a fresh access token using the Refresh grant
    • Use the access token to retrieve the event data using either the API or a Google SDK.
    • ... profit!

    If the refresh token has expired (you don't get back a valid access token), inform the user and have them go through the authorization process again.

    Hope this helps.

    posted in Q&A
  • Access google calendars of multiple google accounts (with user permission)

    Hiya,

    We have a situation where we have users. Each user has 1 or more Google accounts. We want to be able to read events from a calendar using Google APIs.

    Is this something that FusionAuth can help with?

    posted in Q&A google calendar api access
  • RE: Is it possible to limit the number of devices a user can login with?

    This might be useful for visitors in the future: https://fusionauth.io/docs/extend/examples/device-limiting

    posted in Q&A
  • RE: how to implement user invitation

    Hiya @kasir-barati ,

    You can certainly use just a subset of known invite codes. In that case, no need to store the codes on the user.

    Instead, add an array of codes in the self-service registration lambda and have a step check to see that the user provided code value matches one of the known values in the array.

    posted in Q&A
  • RE: how to implement user invitation

    This isn't out of the box, but is relatively easy to implement.

    • After each user is added successfully, create a list of codes in their user.data.inviteCodes field (which can be an array). It's a good idea to have the codes be alphanumeric because FusionAuth's elastic search indexing handles those types of values best. Let's call this user the inviter user. Make sure each code is unique across all users.
    • When a user tries to register with a code, let's call that user the invitee user.
    • Build a page in your application to display the list of user.data.inviteCodes to prospective inviters.
    • Create a custom registration form and have one of the fields be an invite code, to be provided by the invitee user (because they got it from the inviter user).
      • You could prepopulate this via a link by customizing the theme and having javascript pull the value from a query parameter and put it into the form.
    • Create a self-service registration validation lambda.
    • In that lambda, search for the code.
    • If it is not found, add an error. This error will prevent the user from registering.
    • If it is found, take the following steps:
      • Allow the registration to succeed.
      • Add a webhook to listen for the create user event, which reads the invitation code.
      • From the webhook, update the inviter user to remove the used code from the user.data.inviteCodes, which means that code can't be used by future invitees.
      • That same webhook can update the invitee's user.data.inviteCodes field so that they can now become inviters (or maybe that happens later, depending on business logic).

    If invitees use the same code within time period the elasticsearch index is updated (usually 1 second), there may be a race condition that would allow two invitees to register with the same code.

    If absolute isolation in the invite code processing is important, use Lambda HTTP connect in the self-service registration validation lambda to check if a code is valid, and have that read from an RDBMS.

    In this case, you'll need to provide the code and the inviter email address in the form so the lambda can provide it to the API. These fields can both be hidden.

    You can also consider adding an expiry timestamp to the user.data.inviteCodes if that functionality is needed.

    Here's an example of the user.data.inviteCodes value:

    "inviteCodes" : [
     { 
       "invcode": "abc123",
       "exp":  1712679467
     },
     {
       "invcode": "234jklasdf",
       "exp":  183678467
     }
    ]
    

    And here's an example of a queryString that will pull the user with the abc123 invite code, or return zero records if that is not found.

    data.inviteCodes.invcode:abc123
    

    Read more about elasticsearch arrays.

    posted in Q&A
  • how to implement user invitation

    I have an application that I want to invite users to and want users to be able to invite users to. I do not want to allow users to register for this application without being invited.

    I've seen: https://fusionauth.io/community/forum/topic/935/how-to-implement-user-invitation but was wondering what the current best practice is.

    posted in Q&A
  • RE: Connector service docs say it needs only user.id, but fails it not given email too

    @fusionauth-qhj5e

    Hmmm. Which docs were you looking at?

    https://fusionauth.io/docs/lifecycle/migrate-users/connectors/ says:

    If you are migrating a user, you must provide the following fields in the user object you return.

    user.username or user.email
    user.id: a FusionAuth compatible UUID
    

    and

    If you are authenticating a user, you must provide the following fields in the user object you return.

    user.username or user.email
    user.id: a FusionAuth compatible UUID
    

    If there's another place in the docs that state that email/username is not required, would love to correct it.

    posted in Q&A
  • RE: Assign a user role when a user logs in using Google

    This is possible today using a Google Reconcile Lambda. Our Lambdas allow arbitrary JavaScript to be executed during a login event. You can write logic to check the user's domain and assign them the appropriate role associated with the FusionAuth Application they're authenticating through.

    Below is a code example demonstrating how you could implement such logic:

    function reconcile(user, registration, idToken) {
      
      function extractDomain(email) {
        // Split the email address by '@' symbol
        var parts = email.split('@');
        // Return the second part which represents the domain name
        return parts[1];
    }
    // function to extract the email domain from the user object and stores in domain variable
    var domain = extractDomain(user.email);
    
    
      // Conditional statement checks domain for fusionauth.io and adds 'counsellor' role, if any other domain exist adds 'user' role
    if (domain === 'example.com') {
      registration.roles.push('teacher');
    } else {
      registration.roles.push('user');
    }
    //This is optional, but is good to have for debugging purposes. The results will be returned in the event logs.
     console.info(registration.roles);
    
    }
    
    
    posted in Q&A
  • Assign a user role when a user logs in using Google

    Hey, I am just curious if it's possible for us to assign user role if we choose to do login using Google as identity provider (we directly call Google for sign in, then link the user to FusionAuth, as per this guide).

    To elaborate more, let's say we want user to be assigned to the user role upon sign in. But if the user email is under the domain @example.com, we want to assign them as teacher role. Would it be possible?

    posted in Q&A
  • RE: Simple session management service

    The best solution here would be to use entity management.

    You can create an entity type of Session or similar.

    Each time you have a user log in, you can create a Session and set the .data.session_identifier field to the value of the device fingerprint + business specific indicator, and store the access token as the value.

    When you are trying to find whether a user has a valid session, you can use the Entity search APIs to find that key and get back the value. Or, if the value doesn't exist, the user has no valid session.

    For expiration, you can use the access tokens exp claim (which means anything consuming it will have to check that, which it should anyway). You could also manage additional expiration metadata in the .data field if you needed different logic (you have 5 hour access on weekdays, 10 hours of access on weekends or something similar).

    Note that you should be vary aware of the security implications of this scheme (for example, that the device fingerprinting is unique and that the access token is narrowly scoped enough that if it is somehow obtained by an attacker it can't be used to damage the system)

    posted in Q&A