I'm trying to use standard (official) Okta Sign In Widget - I need a way to fill out some fields automatically on that Registration Widget. For example User Name and Last Name.
I know that I can do it through API, but wondering if there is a way to use query string parameters or something like that.
Wondering if there is a way to do that?
Related
I am building an API where users and admins can interact with the same data, but with different needs.
A user can also have access to the admin panel, if he has the "admin" role.
Let's see for example we have a resource like Badges. A Badge is simply a reward when you achieve some actions into the app.
GET http://localhost/api/v1/badges
An authenticated user can call this endpoint and it returns the list of all badges, if they have it or not, with progress details.
GET http://localhost/api/v1/badges?user_id=2
with user_id parameter, we can see these details of another user (if he allows it).
But from the admin scope, I just need to see the list of all badges, without achievement details (CRUD operations).
So I have 2 options in mind:
Create "admin" endpoints: GET http://localhost/api/v1/admin/badges.
Adding custom header "X-App-Scope" to identify if I am in admin or user.
I don't like the second one because I think I will have so many if statements and behavior in the same endpoint, depending of the scope.
Because I have lots of use cases like this, I want to make sure my API architecture is good to handle user/admin needs.
Do you guys have any idea/example to manage stuff like this?
Thanks!
My personal preference is to separate admin API routes from user ones. i.e. having two routes
/api/v1/badges
/api/admin/v1/badges
You will have two unique documentation, one for each route, which makes it easier to maintain and understand
It will be easier to tell the difference between the user and the admin versions
There is no need extra code to check for request headers or url params.
It makes your middleware less complicated, especially if authentication and permissions are handled there.
It is more scalable for teams as there is only one kind of request and response format per API.
TL;DR: REST is designed in the expectation that you would use two different resources here.
The core problem is this: how would a general purpose component, like a browser, know that your special resource needs to have this custom header added?
In particular, consider the case where I send to you a copy of the URL for this resource, and nothing else. How are you to know to add the customer header to the request?
On the other hand, if you use different resources to share this information with each audience, everything just works.
The only way I found to stay as simple/clear as possible is to make multiple endpoints, for each use case:
GET http://localhost/api/v1/badges to get all badges in raw data
GET http://localhost/api/v1/users/badges to get all badges with user stats (progression, achievement...) in a transformed format
GET http://localhost/api/v1/users/{uuid}/badges to get all badges with user stats (progression, achievement...) in a transformed format for the specified user, if his profile is public
Now I have a lot of /users/XYZ endpoints, but my code seems easier to read & maintain, and I don't really need to see the code to guess what data will be returned, the conditions, etc...
I keep wondering how the other APIs are written when you have an admin section, because having /users everywhere isn't really "pretty", and I don't see that anywhere else.
I'm using Lambda functions, executed via API Gateway using a Cognito User Pool Authorizer.
I know I can get the "standard" user attributes (like sub, email, cognito:username, etc.) from event.requestContext.authorizer.claims.
But this does not include custom user attributes (like custom:myAttribute).
I know I can get them via adminGetUser, and this works, but I wonder whether I can save this call and somehow get those custom attributes automatically in the event?
Have you already looked at this doc for custom claims?
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-enable-cognito-user-pool.html.
You will need to define context in following manner for custom attributes:
{
"context" : {
"role" : "$context.authorizer.claims['custom:myAttribute']"
}
}
After you add a custom attribute to a Cognito user pool and assign a value to it for a user there are a couple of reasons why it won't appear in the requestContext.authorizer.claims collection.
The first and most obvious is that you need to make the custom attribute readable via the app client you use to generate the ID token you are authenticating with. If you are using the AWS console this is done by navigating to App Clients -> Show Details -> Set attribute read and write permissions then tick the attribute(s) you want to make visible to your Lambda.
The second reason for your attribute not appearing, even if you have completed the first step, is that the user's claims are encoded in the ID token you generate. This means that if you're using an ID token created before making the attribute(s) readable you still won't see them. The solution to this is to just generate a new ID token for your user at which point you should see the attributes in your Lambda's request context.
I am using Okta C# sdk for development. I have created some custom user profile attributes in the Okta. I am able to create user and save values in custom attributes.
But as I saw that when you update profile data you have to provide all the details again. If you provide specific attributes value then sets null for other attributes. So how can I update only one or two attributes so that other should not change.
Dinesh.
You can use a POST /users/:id if you want to make a partial update. Make sure not to use a PUT for this operation else you will wipe out the remaining values that are not in the Request
I'm assisting another developer with adding a link to a page in a product called Lawson that we use in-house. I need to pass the authenticated user's employee ID to an HTML page we're bolting on. I'm still looking at existing pages on the server, but thought I'd ask: does anyone know how the Javascript object that represents the authenticated user works? It looks like something server-side must be dynamically creating a Javascript object that has useful properties. It is usually called 'AuthUser'. I want to add the necessary JS references to my new page to support this object and access its properties. Does anyone have any experience with that? Thanks!
If you are in a portal session, you can access this in javascript through attributes of portalWnd.oUserProfile:
alert(portalWnd.oUserProfile.getAttribute("id"))
This will give you the logged in user's short username. Many other attributes are available. To see a complete list, log into a portal session and then replace the URL with:
http://YOURPORTALSERVER/servlet/Profile
I'm not sure what you mean by "bolting on", but if you want to pass an attribute to an external page launched from a Portal session, you could create a user shortcut via Portal preferences using something like:
javascript:window.open("http://yourserver/yourpage.html?user=" + portalWnd.oUserProfile.getAttribute("id"))
as the target and process in yourpage.html like a normal GET method form.
If you are still puzzling over this all these months later, provide some specifics if you need more guidance.
I'm trying to figure out how should I integrate facebook login system in my existing application through facebook c# sdk.
I have a web forms application and I'm authenticating users by standard Login control.
I'm using MembershipProvider, RoleProvider and ProfileProvider.
I'm thinking I should persist FacebookUniqueID and put it into relation with existing informations on my Membership Users table.
I'm wondering wich is a correct approach to this.
Considering I have a custom Profile Provider that uses a custom sql table, it would be fast to add a FacebookUniqueID property to my user profiles and use it in my login workflow:
Login through facebook;
retrieve facebookUniqueID;
retrieve userName for the user that
have this specific facebookUniqueID,
then
FormsAuthentication.SetAuthCookie(userName, bool);
What about providing an overload for the previous method taking facebookUniqueID as parameter?
Please let me know what do you think about this from any perspective and if anyone knows a simple working example
I think you are on the right track. We implement a similar solution (though we have rolled our own custom membership/role/profile etc and don't use the built in approach.)
You also will have to handle the situations that occur when a new user (without an existing account) logs into your site via Facebook.