@alex-patterson Thank you for sharing this. I did not even notice this in the documentation. I will give it a try.
Best posts made by mou
-
RE: Planing to use FusionAuth entity based RBAC, but it is not clear could it cover full CRUD.
-
Planing to use FusionAuth entity based RBAC, but it is not clear could it cover full CRUD.
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
- Projects
- Teams
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?
- Root (a singular object for defining global roles and permissions)
Latest posts made by mou
-
RE: Looking for workaround for GitHub's email hiding.
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.
-
Looking for workaround for GitHub's email hiding.
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?
- try to perform GitHub
-
RE: Implementing GitHub-like "Personal Access Tokens"
@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.
-
RE: Implementing GitHub-like "Personal Access Tokens"
@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" }
-
RE: Implementing GitHub-like "Personal Access Tokens"
@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.
-
Implementing GitHub-like "Personal Access Tokens"
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:
- The user navigates to their profile.
- They access a specific section dedicated to API integration.
- Upon clicking "Generate Personal Access Token," they see a token that can be easily copied.
- 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!
-
RE: Planing to use FusionAuth entity based RBAC, but it is not clear could it cover full CRUD.
@alex-patterson Thank you for sharing this. I did not even notice this in the documentation. I will give it a try.
-
Planing to use FusionAuth entity based RBAC, but it is not clear could it cover full CRUD.
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
- Projects
- Teams
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?
- Root (a singular object for defining global roles and permissions)