It always updates my user profile instead of the user that I specify in X-Slack-User:
https://slack.com/api/users.profile.set?token=yadayadayada&X-Slack-User=XYZ23456&Content-type=application/json&charset=utf-8&profile={"status_text": "Test #1","status_emoji": ":gb:","status_expiration": "5"}
The user Ids that I tried to specify are valid ones, I'm an admin and I created an app with the required rights, the legacy token did no good as well, this works, but just for my user, X-Slack-User is not working in my case.
I'm on a free plan so passing "user" as a param doesn't work for me, as states the API: "ID of user to change. This argument may only be specified by team admins on paid teams."
Is there maybe another way to update the status of other users on a free plan Slack?
As you already stated the API method users.profile.set can only be used to change the profile of other users if you are an admin and on a paid team. A property X-Slack-User is not part of the API, so it will not work either.
There is a workaround for teams on a free plan tough:
The API method will always work to change the profile for the owner of a token. You could collect tokens from all you users and then use those to change the status for each user. For that each user will have to install your app though OAuth once. This will create individual tokens for each user, which your app needs to store. This is called "configurations".
Related
I have a custom application for internal use only where currently users are created by a super admin. Some of the users are from within the business and some external e.g. suppliers/customers.
I'm looking for a way to integrate MS Active Directory as a login option but want to be able to restrict which users from the business can actually use this method.
I have search through all the MS docs and have all the documentation on the different oauth approaches but not sure which one would be suitable for my needs.
I am thinking that perhaps i need to give the admin a way to browse the AD and select the users that can login which then creates inactive user accounts in the mysql database with some sort of MS user ID. Then provide a 'Sign in with MS' button that does the usual auth redirection process to MS and back to the site. At that point I can check an ID and if that matches an allowed user account and if so, sync the rest of the data e.g. name, email, phone etc..
Links I've already found:
https://learn.microsoft.com/en-gb/azure/active-directory/develop/authentication-scenarios
https://learn.microsoft.com/en-gb/graph/tutorials/php
https://github.com/microsoftgraph/msgraph-training-phpapp/tree/master/Demos/03-add-msgraph
Your first order of business is enabling a user to sign in to the Laravel-based app. For this, I strongly recommend not trying to re-invent the wheel (at least not completely), and make use of an existing Laravel package. Laravel Socialite is probably the best place to start, since it has a long list of existing community-provided Socialite providers, including three which work with Azure AD already: Microsoft, Microsoft-Graph and Microsoft-Azure. (Note: Though I haven't tested any of these myself, the first two seem to be the most promising, as they use the newer v2 endpoint.)
When it comes to authorization (controlling access), you have two options:
Control at Azure AD
Once you've got the app integrated with Azure AD, you can configure the app in Azure AD to require user assignment, and then control access to the app by assigning (or not) users to the app. Users who are not assigned won't even make it past the sign-in page.
You can use Azure AD's existing experiences for managing user and role assignment for the app, or you could go all-out and build this experience directly into the Laravel-based app itself, making use of the Azure AD Graph API to create the [app role assignments](https://learn.microsoft.com/en-us/previous-versions/azure/ad/graph/api/entity-and-complex-type-reference#approleassignment-entity and user picker experience.
Hint: In either case, remember that you can make the app "superuser" an "owner" of the app in Azure AD (Azure AD > Enterprise apps > (app) > Owners), which will allow them to assign users without needing to give them any additional privileges in Azure AD.
Control at the app
In this approach, you allow all users to sign in to the app with Azure AD, but then you use your app's own authorization logic to decide who makes it any further, and what roles they get in the app.
In reality, you will most likely find the best approach is to use a combination of the two, with some of the authorization enforced by Azure AD and the next level enforced by the app itself.
If you would do it in this way, it will be necessary that the super-admin has always this permissions in the AAD. From my point of view it is less practical.
I would perfer such app-assigments with help of Service Principal. You assign a role (look for app roles) to the user and then your business logic must decide which permissions the user has. If you would use the app roles feature, then you can restrict access to the role with it's help. All the user can login, but only users with a specific role would be able to see a content of the app.
I hope this hints can help to find a right direction, but there is no silver bullet solution... :/
Is there any way to login other users account for admin user ?
Currently authentication based on Meteor Accounts
I saw this post but didn't working at all now.
The feature is important for us because when user have problem in system then admin need to see it this by simulating user account.
Thanks in advance.
It seems you want to impersonate a user. This means that you want to have Meteor.userId (or this.userId depending on context) reflect the _id of a specific user both on the client and the server.
afaict the only way to do this is to login as the user. Presumably you don't want to ask the user for their password so you have a couple of choices:
Save their existing password, replace it (temporarily) with a password of your choosing, then after you're done impersonating their account, restore their existing password.
You probably don't want to ask the user for their password and you don't need to. All you need to do is set aside Meteor.user.findOne(userId).services.password.bcrypt, then reset the password to your temporary value, then restore the original bcrypt value later.
The downside is that the original user would not be able to login while you are logged-in. Plus it's really hacky.
Extend Meteor's Accounts package to provide impersonation capability in a more elegant manner.
You might also look at validateLoginAttempt. The docs are unclear as to whether a failed login attempt could be overridden with a successful one but if it could then that would provide another pathway to solve your problem.
Instead of logging in as the users, which requires their password and which is a total no-no, you may use rather alanning:roles and allow the admin to assign the role of any user in order to draw views based the user's role.
This requires a well designed role system.
As a plus you could then at least load the documents associated with the user who you want to support.
This requires a well designed document and data model.
But generally spoken you should rather focus on writing good tests (test driven development) for components as unit tests, integration tests and UI tests.
This will reduce the need to manually view the app as an end user a lot.
The most common end user problems can be reduced by creating a good knowledge base like a wiki or video tutorials.
Even if then an error occurs in the end user side, I would rather try to implement a well designed error log that allows users automatically create tickets on error which also include the error stack.
All the above methods are to be favored before logging in AS THE USER.
As #Jankpunkt has already mentioned alanning-roles I can add something you can use without installing any external package.
Just keep a type key in the profile object of the users collection. Then define some types like 1 for super-admin, 2 for admin, 3 for general etc. Then check the authorisation of particular action by checking the value of user.profile.type key.
Caveats: Make sure you are checking the type in server side. By default profile field is writable from the client end, so if you are putting type field in the profile object make sure that you are not allowing users to modify users collection in the client end.
Here is how to restrict client end update in users collection:
Meteor.users.deny({
update() { return true; }
});
Read more on roles and permissions here:
https://guide.meteor.com/accounts.html#roles-and-permissions
We are trying to integrate our platform with Pipedrive. As far as we have researched, in a pipedrive account, there is one admin and he can add multiple users. And the users later can login in their respective accounts.
What we are trying to make sure is that once a Pipedrive account is integrated with our platform, the same account should not be integrated twice. So, I need a unique identifier, that lets me know whether the account has already been integrated.
My initial approach was to check the api key. But it was not successful, since every users in an account have different API Keys.
After a bit of research, I found out that there is an identifier called company_id which is common for all the users in an account. But I could not find anything regarding it in documentation. So, I am not 100% confident to go ahead and implement it in our code.
Does anyone have an idea about this?
Pipedrive support rep here.
The most sure-fire way to ensure this is to make a GET request against http://api.pipedrive.com/v1/users?api_token=your_token_here.
You are correct in assuming the company_id in the additional_data object in the response is static and won't change across any users on the account.
Note that a Pipedrive account may have more than one admin, and that non-admins (regular users) might have visibility (and editing) restrictions in place, which may cause some of your GET, PUT and DELETE requests to fail.
In case you're not doing this already, I'd thus advise filtering the data array from the abovementioned endpoint for user.is_you to equal true and check whether the is_admin property is set to 1 during "registration" to ensure the user setting up the integration is an admin.
Hope this helps!
I'm not quite sure what you're asking for. Are you looking for a unique identifier for each user?
Each user has an id, you can get all users by calling
https://api.pipedrive.com/v1/users?api_token=____
This will return a JSON Object with data on your users, including their names and associated IDs. Admins are just users with different privilege levels. All admins are users, but not all users are admins. All users are part of a company, the company is identified by the first part of the Pipedrive account url ie.
https://FooCompany.pipedrive.com
Are you trying to see if a certain company has been integrated already?
In messaging platforms like Slack and HipChat you can integrate apps that can post messages to groups without them being sent from a user e.g.
Defect Management System: A new defect was logged at 12pm
Instead of:
John Smith: A new defect was logged at 12pm
Is it possible to do the same thing in Yammer?
There are two options available for you:
1 - You can create a new user on Yammer, name it however you want (e.g., "Defect Management System" with a snazzy avatar), then take the user's OAUTH token and use it to impersonate that user programmatically. This is fine for quick development.
2 - You can create a new user on Yammer, name it however you want, then register a new app on Yammer to get a permanent token and client ID, then use those to impersonate that user programmatically. This is the right way to do it. You can read more about how to do this on https://developer.yammer.com/introduction/#gs-registerapp.
This is an example of a user that we impersonate. It is a bot on our network. It is a separate account in AD and is registered as an app in Yammer and interacts with Yammer automatically.
You are always impersonating a user in Yammer via the API, there isn't a way to impersonate a group, in the way that Slack does (i.e. being able to override the username displayed and replace it with a bot for example in your payload)
If this app is for internal use, you could consider creating a dummy user as a bot to post defects, and then using Custom Object Types & Actions in Open Graph to further customize the messages. Obviously there are some business & administration considerations in doing that, not just development ones.
I made a members-only site that uses Google oauth2 to authorise users. The site is built with the Laravel framework and Artdarek's oath library.
When the authorization callback comes from Google, I lookup the user record in the DB by email and proceed to the protected page if the record exists, otherwise to a register page.
The problem is some of our members use two Google accounts. One user registered via his primary account (e.ge. a#gmail.com). The next day he returned and mistakenly tried to login with b#gmail.com. Naturally the system showed him the registration page. From that time on each time he visits the site the authentication mechanism sees him using his second (unwanted) set of credentials.
To resolve this one case I instructed him to logout of all accounts (on both sides), clear cookies and start from scratch but this is not a practical solution for all users. In same cases even this measure does not seem to correct the problem.
How can I solve this case? What is the right way to request oauth authentication and get them back from the right account? Can I force Google to ask the user with which account to proceed?
Google will automatically ask the user which account they want on an oauth request if they enable the account chooser.
I have logged into my Google Apps and my Google account, so for me on an oauth request, I get the following prompt:
In order to do the same for your user, they have to click "Stay signed in", but of course this is not advisable for public computers.
Beyond the above, I'm afraid not much can be done. - if they logged in with a#gmail.com at that time, these are the credentials you will receive.
They way I solve this problem is to have a field where the customer can add additional emails, and select one that is primary. I will then inspect against these emails when a request comes in to avoid duplicate user accounts.