I am working on a website's internal applications and what we want to do is to programmatically update our sales force data via api. For example, to update some entities on a a cronjob etc.
Generally this seems to imply the need for an admin type user that can acquire an access token and make REST Api calls. We could go about doing that, however, salesforce requires a password change every 60 days. How can I get purely programmatic access to our salesforce account?
Thanks in advance.
You're correct that it is a best practise to set up a dedicated API/Integration user. You can make a permission set with the "Password Never Expires" system permission enabled. Add that to your integration user and you're good to go.
Related
I have an application and I use Cognito + Identity provider to use google accounts as my users. In Cognito, I have several groups, and in my application itself admin users can add users to groups, remove them from groups, and so on. The thing is, for these changes in the user to be reflected, the affected user needs to logout and in again in the application.
Having a new token fetched on every page load/request does not seem like a good practice. Therefore, I was looking for a Cognito function that would allow me to log a certain user from all it's active sessions. I looked for functions such as logout and revoke, but they require that I have the affected user's access token - which I obviously don't. After that I started playing around with other functions that could have the same effect, such as AdminForgetDevice - I thought that by forgetting a device maybe Cognito would log you out, but that is just used for 2FA, which my application doesn't support.
Seems to me a pretty basic thing what I'm trying to do, and kind of impossible to think that Cognito doesn't support it. Am I asking the wrong question? Is there an endpoint to accomplish this, or a different token-retrieval approach that I should use? I just want to make sure that if a user's groups were changed, those changes reflect immediately. My approach right now is forcing all that user's sessions to end.
I reached out to AWS support asking about this, and their official answer is that Cognito has no action to end all sessions of a specific user immediately. But I came to a solution on my own. You have two options:
1. User global signout and wait 1 hour until the user session is expired.
Not a fan of this solution. If you removed access from a user, makes no sense that the user can still use their old permissions for an hour.
2. Make your interface aware that the user should be logged out and use the logout function
This is the approach I'm going with. The moment an administrator changes a user's permissions, I am creating a notification for that user. The interface, once the user accesses it, know that there have been changes to that user because of the notification. The interface, then, in possession of the user's accessToken, can simply call the logout function.
I have a flask website.
i would like the user to be able to schedule repeated requests for data from one of their Google accounts (let's say Gmail).
From within the website, the user would first authorize the application to access their private Gmail data. From then on, the application, would retrieve the user's Gmail data on a re-occurring basis, without needing to get authorization each time.
Is this possible? I know it would require a service account but can anyone point me in the direction of documentation that describes how this particular scenario might work.
Would such a scenario be allowed to persist long term? Or will their come a time when Google will require the user to reauthorize the application?
Correction, you should not use App Passwords. OAuth is the correct way to do it I believe:
https://www.oauth.com/oauth2-servers/signing-in-with-google/
Here's Google's docs on it, which is more specific to your need:
https://developers.google.com/identity/protocols/oauth2
I'm building a nutrition skill and I want to include some calculators. I could have Alexa ask for the parameters each time something is calculated, but I'd prefer to have users set up a basic profile for themselves to store age, height, and weight values.
I found a small section of Amazon's documentation that talks about how the userId element could be used to store attributes across sessions. Will that work for what I'm talking about though? Or will I have to add OAuth?
There are two way to do this:
1) You can use sessions.
In this method, your data will be vanish when session is end (user stop talking with your skill)
more details https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/alexa-skills-kit-interface-reference#session-object
2) You should implement an oauth 2.0 server to store user data. It is not that easy but you can find some oauth server example in here https://oauth.net/code/
For connecting your skill to your oauth server, you can follow here
https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/linking-an-alexa-user-with-a-user-in-your-system
bonus: If you do not want to implement an oauth server, you can use Login with Amazon (or login with google) services. But you will still need a database server to store data
The userId that you get on your requests uniquely identifies an Amazon account, not a person. Despite the option to switch between different accounts on a single device (see: https://www.amazon.com/gp/help/customer/display.html?nodeId=201628040), the feature to identify people has been discussed (http://time.com/4683981/amazon-echo-voice-id-feature-2017/) but it's not available yet.
As already mentioned in the comments, you will need to persist the session information between sessions and you could use the userId to identify each account.
But in any case, you don't need account linking or using Oauth to simply identify a person.
Additionally, I'd recommend you to stay within the Amazon ecosystem and run your stuff in Lambda (with free tier and with development credits for developers publishing Alexa skills).
If you need help getting started, I have a single-file template for Alexa skills using Python and several examples:
https://github.com/josepvalls/ask.py
I have an application that is run on multiple user systems, and using OAuth, allows the users to log in via Facebook, Twitter, etc. The entire point of the user logging in is to get settings and actions that the same user made while logged in on other computers, as identified by logging in with the same OAuth provider + provider user id. The application itself is written in C++ using Qt.
My question is this: how can I save the settings that a user made, and allow them to retrieve it in a secure way? I have a centralized server that I can store information using MySql tables, but I'm not sure the best way to have the user application prompt the server, and receive the data stored for that user.
Any ideas or places you could point me towards?
There are several ways I could think of with this, all have trade offs:
Generally I would store the data in mysql using some kind of string or object encryption/serialization method. I do not use Qt much but http://qt-project.org/wiki/Simple_encryption has some examples of very simple encryption that could be used.
Then the question becomes: What do you use as the key? I would go either with the key provided by OAuth for that user (which could be an issue if users de-authorize the app but still want access to this data) or some other user provided key (which is counter to using OAuth in the first place).
Another option is to go with Qt Users session http://qt-project.org/doc/qt-4.8/qtwebkit-guide-cache.html
This would maybe remove the need to encrypt since it should only be accessible within the users scope.
NOTE: Based on comments below it seems the issue is more about securing communication with the MySQL versus the data inside of MySQL. Waiting on user comments to revise my answer.
I'm writing a Facebook canvas webapp that performs a login (using urllib) to a third party website and performs actions on behalf of the user. This means I have 2 accounts; the account the user has with my webapp (via facebook) and the account the app uses to perform a login on their behalf (with user/password details provided by the user).
I obviously don't want plaintext passwords in the DB. But I also don't want the user to have to enter their password every time they perform an action. I want them to enter the password once when they sign up, and I want to encrypt the passwords, but what do I encrypt against?
Any key on the server would be available to anyone who had gained access (i.e. useless), so I was thinking of encrypting it against a value available via the Facebook API.
When the user logs in (and gives the app their access token), the app can request the value via the API and encrypt/decrypt their 3rd party password with this. Anyone with access to the server wouldn't be able to make this request without the user being logged in to the app. (This still means someone snooping on the server could get logged-in users 3rd party password, but anyone who got one-off access to the DB couldn't see passwords.) Is this wishful thinking?
You might as well encrypt it using a key on the server. If anyone gains access to your server they will have everything they need to retrieve the key even if you're getting it from Facebook.
I think the best you can do is to store the key in a location that isn't available to your webserver, but that is available to your script. At least make sure you don't store the key in the database.
Whatever you do beyond that would just be security through obscurity. The key here is to keep your server secure so that no one gains access to it.
I guess you could store the logins ONLY on the client, in some sort of local storage and do all the actions related to the third party, from the client in JS.
This of course would need some change in the architecture of your app if you tought to do all this from your server, but that would possible for sure, you can event make client JS send data to your server after it worked so you can log data from the interactions with the 3rd party.
Furthermore it has the advantage of distributing the load on the clients
I know you didn't tag the question with javascript and you seem to want a server pure solution, but It seems the best solution to me. the user keeps its data ..
Security through obscurity might be your best bet. Perhaps implement an algorithm to generate the key using something standard (like the current datetime). You can store the date in your db, and use that to generate the key using your own algorithm.