How do I read the users from workitem-state in workflow workitem, RTC?
I want to compare the logged in user with the current state users. Because I want to enable and disable the permissions depending upon the states.
As a starting point, you can check out the question "work item customization: getting current user as logged in user".
It includes:
var getAuthenticatedContributor = com.ibm.team.repository.web.client.session.getAuthenticatedContributor;
var loggedInUser = getAuthenticatedContributor().itemId;
Related
We're using this library Google.Apis.Auth.OAuth2 to request the user to enter oauth credentials.
https://developers.google.com/api-client-library/dotnet/guide/aaa_oauth
This line
var precreds = GoogleWebAuthorizationBroker.AuthorizeAsync(
clientSecret,
scopesList,
emailAddress,
CancellationToken.None,
new FileDataStore(AuthStorageDir)
);
var creds = await precreds;
This will popup a browser and request the user to click on the correct oauth account.
The issue is the emailAddress. In the documentation some places show its being set to "user" and other places say "the user to authorize". We're using the latter interpretation and are providing an email address. But the user could click on a different email address.
Does anyone know what is the correct interpretation?
If we are correct and an email address can be provided, is there a way to detect the email address they clicked on? and then popup a warning message.
I was also wondering what this user information is in GoogleWebAuthorizationBroker.AuthorizeAsync and was searching for an explanation as it is documented very poorly. I think I found the answer in the comments of the following topic: Check if user is already logged in
It is only an information about local users and has nothing to do with the user authenticated against the api. It only enables you to switch users in your application if you need this e.g. For every user an inidividual response file ist stored on your machine: C:\Users\WindowsUser\AppData\Roaming\Google.Apis.Auth\Google.Apis.Auth.OAuth2.Responses.TokenResponse-AuthorizeAsyncUser.
I will check this today in the evening.
I am trying to create an app using firebase auth and firestore where new users can be invited via email to work on a project. The problem is, I do not know the best way to store the temporary user project permissions before they have a uid. I want the user that got invited via email to get access to the project upon opening the link sent to them.
I had tried two different ways
Having a sub collection doc for every user in the project
/project/{projectId}/users/{userId}
When a new user is invited, the userId was set to their email, having a cloud function that triggered when a new user was created to send the invite email to the user. Once the user opened the link, it deleted their user document and a cloud function ran that created a new doc with the users id now that they had once since they were authenticated.
This worked, but left a 10 second period where the user can't interact with the project because the cloud function for making the new user doc is running. Also it just seemed like a bad way to do it.
Having a single document with all of the user information
/project/{projectId}/users/users
users:{
roles: {
users_id: 'admin',
new_user_email: 'admin',
}
}
This one I was not able to get to work as firestore does not let you create a key with a period in it, but if there was a way around this, it would work as well. I had also set up firestore security rules which made it so they could only edit fields where the key was there uid or their email if they were not an editor/admin.
Consider creating an anonymous account in Firebase Authentication first, which requires no input from the user. It will receive a UID that you can use to store data for that account. Then, you can convert that account to a normal account after the signup or login succeeds.
Since you didn't say which mobile platform you're using, I linked you to the web docs, but the procedure is generally the same for each one.
I am using Cognito User pools and the hosted Cognito UI. I want new users to be disabled when they first sign-up.
I am trying to use a Cognito Trigger to disable the user.
The "Pre sign-up" trigger is to soon, the user has not been created yet. I have successfully used the "Post confirmation" to disable the user, however this is causing a side effect. After the user enters the confirmation code which is emailed to them, they see this message in the hosted UI "User is disabled".
Does anyone have a suggested solution on how to make the new users disabled by default?
We had a similar Business Requirement. For us we made use of a User Pool Group. This allowed the sign up and validation process to work as normal. We had the Post Confirmation trigger send our product team an email with details about the new confirmed user. We had a simple UI for the product team to add the group to a user if they should have access.
To Deny/Grant Access to the app: Our app checked the ID Token, once a user successfully authenticated, for the group (the ID Token has a 'cognito:groups' key which contains a list of all the groups the user is in). If the group was not present we displayed a page showing the user a customized access denied message
Situation
Let's say an administrator of a site removes a user from the Admin role and adds her to the Contributor role. According to the site's database, that user has been demoted and should no longer have access to Admin-only features. Now the user comes back to the site some time after that change, but had logged in sometime before the change and is still logged in. So long as that user does not log out, she will continue to have claims that say she is in the Admin role. If she logs out, or gets logged out, she loses the claim that she belongs to the Admin role and when she signs back in receives the new claim of belonging to the Contributor role.
Desire
What I would like to happen, perhaps the next time the user requests a page from the site after the administrator made the change, is have that user transparently lose the Admin role claim and gain the Contributor role claim without them having to sign out or do anything special. In fact, I would prefer they are unaware of the change, except that her menu has changed a little because she can no longer perform Admin-only activities.
How would you handle this situation in a way that is invisible to the affected user?
My thoughts
I am using ASP.NET MVC 5 and ASP.NET Identity, but it seems like a solution to this could be easily generalized to other claims based frameworks that utilize cookies. I believe that ASP.NET Identity stores claims in the user's cookies by default in MVC 5 apps.
I have read the following post along with many others on SO and it comes closest to answering this question but it only addresses the case where the user updates herself, not when someone else like an administrator makes the change to her account: MVC 5 current claims autorization and updating claims
There is a feature in Identity 2.0 which addresses this, basically you will be able to do something like this which adds validation at the cookie layer which will reject users who's credentials have changed so they are forced to relogin/get a new cookie. Removing a role should trigger this validation (note that it only does this validation check after the validationInterval has passed, so the cookie will still be valid for that smaller timespan.
app.UseCookieAuthentication(new CookieAuthenticationOptions {
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/Account/Login"),
Provider = new CookieAuthenticationProvider {
// Enables the application to validate the security stamp when the user logs in.
// This is a security feature which is used when you change a password or add an external login to your account.
OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
validateInterval: TimeSpan.FromMinutes(30),
regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
}
});
I have to programmatically create a task for a user that was not explicitly added in the site users. He has permissions to contribute to the task list, though, because he belongs to an AD group that has been granted those permissions. I can assign the task to the user through the UI; how do I do it through code though?
The accepted way of assigning tasks to users is to set the AssignedTo field of the task to an SPFieldUserValue pointing to that user. Except it cannot be done in this case, because the users cannot be found in SharePoint, only his group! Assigning the task to the whole group is a bad idea, for obvious reasons. And our system administrators categorically refuse to add the users to Sharepoint one by one, because that would duplicate the data they have in Active Directory, and generally be a pain to manage. What do I do?
When a user authenticates to SharePoint, an entry is created for them in the profile store, even if their permission to the site comes from an AD group.
I did a quick test by adding new user (TGroupsUser) and group (SPtestPermissions) to my AD, so there is no chance the user was ever on my site before. I added the user to the group and gave the group "Member" permissions to my site. I then authenticated to SP with this new user.
To show that the user is part of this SPWeb, I wrote a quick webpart to enumerate the users on the web. Note that there are three groups of users with the SPWeb. All Users, Site Users and Users. See this link for full description of these properties. Basically, users are users on the web. Site Users are users and groups on the site collection. All Users is all users of the site including those granted direct permission or granted through group and then visited the site. Here are the results, minus the system accounts.
All Users
SPSDEV\rross
SPSDEV\sptestpermissions
SPSDEV\TGroupsUser
Site Users
SPSDEV\rross
SPSDEV\sptestpermissions
SPSDEV\TGroupsUser
Users
SPSDEV\rross
Since this account (TgroupsUser) is part of the user collection for the web, you can treat just like a user added directly to the site. To finish the testing, I created a task with the following code for the assignedTo field.
TaskItem[SPBuiltInFieldId.AssignedTo] = web.SiteUsers.GetByEmail("myemail#domain.com");
Here is a screenshot of the new task assigned to TGroupsUser.
FYI - I needed to use AllowUnsafeUpdates on the web object.