@alex-patterson Thank you for sharing this. I did not even notice this in the documentation. I will give it a try.

Hi, community. I would like to refer to your experience.

We're currently bootstrapping our application and have found FusionAuth to be a great fit. Our model comprises three key resources: root, team, project, and resource, which are organized hierarchically:

• Root (a singular object for defining global roles and permissions)
  • Teams
    • Projects
      • Resources

To expedite our product's bootstrap process, we're considering fully integrating this hierarchy within FusionAuth. This integration would serve not only our RBAC (Role-Based Access Control) requirements but also simplify complexity in the early stages. However, this approach necessitates full CRUD (Create, Read, Update, Delete) capabilities for these entities.

Here's where we encounter our challenge: Although I've gone through the FusionAuth API documentation and understand the basic CRUD operations, there seems to be a gap. Specifically, we need a way to execute queries like "List all projects where a user has role X or grant Y," without maintaining a separate database for all entities. The search API call in FusionAuth appears limited and doesn't seem to meet this need.

This leads to our main question: Is it necessary to store all entities in an additional database to list them as needed, or can FusionAuth manage this internally?

@mark-robustelli Hi, Mark. This is a great idea I didn't even think of. Thank you very much. It is a workaround anyway, but maybe it will allow me to complete PoC and wait for the proper invite flow to be implemented in FA.

Hello, community. I want to share my recent experience in the hope that we can figure out a solution together.

I'm trying to implement an invite flow for our application, which allows users to invite others to collaborate, even if they are not registered in the application. After reading related topics on implementing an invitation flow, I decided on the following process:

1. The user specifies the email of the person they want to add to the team.
2. The application creates and registers a new user, setting sendSetPasswordEmail and skipVerification in an API call.
3. The new user receives an email with a link to set their password.
4. The user sets their password.
5. The user is redirected to the application UI to accept the team invitation.

In reality, everything goes fine up until the new user sets their password. They then see an uninformative screen with no instructions on what to do next or where to go. Therefore, I decided to update the templates for several reasons:

1. To provide guidance and explanations about what is happening ("You were invited to... after setting your password you will...")
2. To instruct the user on the completion page about the next actions and provide a link, or possibly even initiate a redirect to the application using JavaScript.

This seemed like an easy task until I realized that "password reset" and "password set" use the same templates, meaning any changes will affect both flows.

So, I decided to implement conditional branching in the template to display different content for different flows. My first attempt was the simplest possible solution: using a query parameter.

1. I added a query parameter to the URL in the "Set password" email template.
2. Retrieved it in the template using request.getParameter.
3. Added a hidden input to the form.

This worked fine for displaying the form, but after successful form submission, the user is redirected to the complete template without preserving the parameter. So, this approach failed.

Next, I decided to add an additional data field to the user object during creation. If the user does not have an account and the account was created during the invitation flow, it would contain a corresponding boolean flag in the data map/property set. My idea was to access the user object and read the property to identify the flow. If the flag is set, it indicates that the user is not yet properly registered and is definitely not resetting their password.

But this idea was debunked because the "Password set" template does not have the user object in its context. Even though the template has the declaration:

[#-- @ftlvariable name="currentUser" type="io.fusionauth.domain.User" --]

attempting to access currentUser causes a Null Pointer Exception (NPE).

I am out of ideas on how to implement the invitation flow while keeping the user experience less frustrating. If you have any suggestions or even propose a complete redesign of the approach, please do not hesitate to share.

Thank you, @dan for your suggestion. I consider your idea. But in this case, we need to decide to change the linking strategy. If it set to email, this approach will generate new users, rather than linking social login.

@dan said in Looking for workaround for GitHub's email hiding.:

I don't think that will work based on a scan of https://docs.github.com/en/rest/users/emails?apiVersion=2022-11-28 . That endpoint provides info about the current logged in user, unless I'm missing something.

I thought it could be possible because reconcile Lamba would receive a user access token as a parameter. At least such an idea appeared when I saw the lambda signature.

Hi, FusionAuth community.

We are trying to integrate GitHub as an IDP. Since we are using emails for account linking, we faced a very well-known issue with users' ability to hide their emails from API user resources. But GitHub is really important for us and I am on the quest to find possible solutions. So I have two ideas, and want to validate them with the community's help.

Currently, I have two ideas:

• try to perform GitHub /user/emails API call from the reconciliation lambda
• attempt to detect such conditions and alter error messages on a template level, to display more relevant information about the issue and link to the guide on how to make things work.

Is it even possible? Or maybe you have another workaround for this case?

@mark-robustelli Thank you. It is an interesting workaround. I think if we apply encryption on top of the generated string value, it will not disclose user's login.

@mark-robustelli yes. We even tested it. However, the ideal case for end users would be to provide a single token for API calls. But passing Authentication Token to Login API requires to specifying user login (in our case, email). Here is an example request from documentation.

{
  "loginId": "example@fusionauth.io",
  "password": "52h3h9fsjOn2Eh0+NBT3Kf6NcWFHbJ7oPD0sFsHMQps=",
  "applicationId": "10000000-0000-0002-0000-000000000001",
  "ipAddress": "192.168.1.42"
}

@mark-robustelli Thank you for your answer. Indeed, we are considering this option as a last resort. Because Application Authentication tokens are "replacement" for passwords. It is not enough to provide only this token to identify the user, and login identifier should be provided alongside. It is somehow different from reference GitHub implementation.

Hello, everyone!

I'm reaching out to the community for insights on a scenario that I initially thought was common, but I'm struggling to find examples or guides. Perhaps my assumptions were off, or I might not be using the right search terms.

Here's our situation: We're in the process of meticulously designing a robust Authorization and API framework using Entity Framework for our customers. However, this is a time-consuming process, and we're concurrently preparing to launch an MVP for our product.

To add immediate value for our users, especially in a dev/infra SaaS context, we're considering implementing a feature for users to generate long-lived access tokens. These tokens would be used in their scripts and automation tasks. The most notable implementation of such a feature can be found in GitHub.

The envisioned user flow is as follows:

1. The user navigates to their profile.
2. They access a specific section dedicated to API integration.
3. Upon clicking "Generate Personal Access Token," they see a token that can be easily copied.
4. The user can then use this token for API interactions, with actions being internally authorized via FusionAuth. Additionally, there's an option to revoke or delete the token as needed.

Our rationale behind this approach is to establish a straightforward Proof of Concept (PoC) for API authorization. This allows us to hit the market sooner, while gradually evolving our API authorization infrastructure to be more sophisticated over time.

I'm keen to know if anyone has implemented a similar feature using FusionAuth. Any examples, recipes, or best practices would be immensely helpful.

Thanks in advance for your insights!

@alex-patterson Thank you for sharing this. I did not even notice this in the documentation. I will give it a try.

Hi, community. I would like to refer to your experience.

We're currently bootstrapping our application and have found FusionAuth to be a great fit. Our model comprises three key resources: root, team, project, and resource, which are organized hierarchically:

• Root (a singular object for defining global roles and permissions)
  • Teams
    • Projects
      • Resources

To expedite our product's bootstrap process, we're considering fully integrating this hierarchy within FusionAuth. This integration would serve not only our RBAC (Role-Based Access Control) requirements but also simplify complexity in the early stages. However, this approach necessitates full CRUD (Create, Read, Update, Delete) capabilities for these entities.

Here's where we encounter our challenge: Although I've gone through the FusionAuth API documentation and understand the basic CRUD operations, there seems to be a gap. Specifically, we need a way to execute queries like "List all projects where a user has role X or grant Y," without maintaining a separate database for all entities. The search API call in FusionAuth appears limited and doesn't seem to meet this need.

This leads to our main question: Is it necessary to store all entities in an additional database to list them as needed, or can FusionAuth manage this internally?