I'm trying to reconcile Twilio's advice and security best practices.
I initially wrote the app using SID and auth-token.
https://www.twilio.com/docs/usage/rest-api-best-practices says:
"we recommend the use of API Keys"
So I'm converting the python helper rest client to initialize using api key/secret
and since this is a webhook auth, following this security practice:
https://www.twilio.com/docs/usage/security#validating-requests
Using:
https://www.twilio.com/docs/usage/tutorials/how-to-secure-your-flask-app-by-validating-incoming-twilio-requests
However, this only seems to support auth_token
Does this mean there is no way to use API keys in a webhook app?
It seems silly to bother with API key secrets in app config if I'm also having to set the auth_token secret as well.
Twilio employee here 👋
Looks like you've spotted an inconsistency in our guidance. You are correct: if your app receives incoming webhooks from Twilio and you want to validate the signature of those incoming requests, you cannot use API keys to do so - you must use your account's Auth Token.
I just fixed the first doc you linked to so it reflects that guidance. Thank you for raising this with us and my apologies for the inconsistency in our docs!
Related
I am going to make request from postman to https://lms.freedomhighschool.ca/d2l/api/lp/1.30/users/
but after request i got message
{ Errors: [ {Message: "Forbidden"} ] }
I have Application ID and Application Key but don't understand how to use this data in my request
I highly and strongly recommend you consider switching from D2L's proprietary ID/KEY AUTH over to the Brightspace API OAuth2.
D2L has many resources available on its Brightspace Developer Community. And, even more helpful, is this GitHub repo --> https://github.com/Brightspace/Postman-Collections
In order to get access to DevCop.brightspace.com, you have to be a registered member of the Brightspace Developer Community.
Tool:
Postman (recommended for OAuth 2.0 Apps)
Notes:
Postman is a market-leading API test tool. It is available for free download at www.getpostman.com. You can find Sample Postman Environments and Collections on the Brightspace Github organization. You can find information on how to connect Postman to Brightspace in the Brightspace Developer Community.
Tool:
API Test Tool (ID Key Apps Only)
Notes:
The API Test Tool runs in a web browser and provides an interface to point to an instance of Brightspace, supply an App ID/Key pair, and log in with a given user account. Once authenticated, you can make calls using a straightforward interface. You can find more information about using the API test tool on the Brightspace Developer Community.
Conclusion use this -> API Test Tool if you have Application ID and Application Key
refer this documentation for brief info
To pass API key-value pair in header -> x-api-key
When we configure Server-to-Server Notifications, we Specify our secure server's URL in App Store Connect and the apple server communicates on that URL. but is there a way to authenticate this request?
It is not safe to keep url open without authentication
in case of PlayStore we can use GOOGLE_DEVELOPER_API_KEYFILE_JSON for authentication, but how to do this for iOS server-server notification?
As the comments have already clarified that there is no built in way.
So, here is my work around of this problem.
Apple sends password in the notification which is App secret key which ideal should only be known by API and Apple.
And to verify receipts coming from the App this password must already be stored somewhere (configuration?) in the API.
So I suggest to check whether the password in request matches with the one stored in our API?
If yes then this is a valid request.
If not then it may be sent by a hacker.
My only concern is that does this App shared secret key aka password change? by Apple or developer? If not than this is the solution.
One way to do it is to use Basic auth. As you cannot specify a header you can use the url format: https://username:password#SERVER_ENDPOINT. This will automatically encode the username:password and construct a basic auth header with the encoded string.
Source:
https://en.wikipedia.org/wiki/Basic_access_authentication
I have made a slack app in which I have a bot. I have selected channels:history, channels:read, channels:write under my permission scope, and also I have passed scopes
"scope":"bot channel:history channel:read channel:write"
while doing my oauth2 verification (using python), and I got a response where the scope is
"scope":"identify,bot,channels:history,channels:read,channels:write"
along with client and bot access tokens.
Now when I do an api call to fetch history of a channel in which my bot is invited to, I get
{
ok: false,
error: 'missing_scope',
needed: 'channels:history',
provided: 'identify,bot:basic'
}
Can someone please tell me where I am going wrong. How can I PROVIDE the channels:history scope in my api call. This is really driving me nuts. Should I be using the client access token, ie xoxp-xxxx, instead of bot token, ie xoxb-xxxx ?'
Thanks!
For people having this problem in the future;
your integrated bot has full access to the slack api, whereas a bot in a slack app don't, as it will used publicly. When you successfully finish oauth2, you should get 2 tokens, user access token and bot token. The user token is used to read history from any channel/groups, and the bot access token is used to write to them. This means you constantly have to be switching from user token to bot access token in your app.
Also, remember that bot-user MUST be a member of a private channel which you want him to connect to.
Hope that helps.
Ps, if any found a better way going about this, feel free to answer below.
Since you did not mention it: You also need to specify all required scopes on the admin page for your Slack app under "Oauth & Permission Scopes".
Please help me figure this out. All the FCM docs neglect this part (which makes me think it's something simple that I should know, but I'm new to coding backends). I need to send the FCM FIRInstanceID token to my server (I use Google Cloud, writing in Node.js). When it gets to the server, it is decoded (according to the FCM docs). But how do I get it to the server? The video says, "This is kinda up to you." This is absurd to me, having no clue how to send anything to a server, let alone a token. What's the code for this? Do I need to structure the token in a certain way? How do I know what address to send the token? (www.google.myserver.com???). I would deeply appreciate any help. I've spent so many days trying to figure this out.
More generally, if anyone has set up FCM + iOS + Firebase + Google Cloud and can explain it to me that would be amazing too (there are no resources for this online!) Thanks!
You need to send the FIRInstanceID to your server only if you plan to use it in the future (like to send a message to a specific device).
If you only want to use topics you can skip this part.
To send the token to your server you can use different ways like:
use Firebase Database to store the value in the backend database
implement a http endpoint (like in Node.js) that can receive and store the token, than call the http endpoint from your app with the token (and maybe more information like the username of the user and some form of authentication to protect your backend)
I'm making requests against the Instagram API from a mobile app. Currently, I'm just directing the user to the Instagram auth url and specifying the response type to be "access_token". Specifying this response_type is known as implicit auth.
Explicit auth: response_type=code
Implicit auth: response_type=access_token
I'm trying to get around needing to stand up a web service to facilitate explicit auth. This would be necessary because in explicit auth flow, the Instagram API needs to make a call to a redirect URL and pass in a "code" parameter. The code would then be used by my server-side code to make a final request to Instagram for an access token.
It's much more efficient for a mobile app to use implicit flow because no extra privately-maintained auth service needs to be stood up to handle it.
Instagram supports the following scopes:
basic - to read any and all data related to a user (e.g.
following/followed-by lists, photos, etc.) (granted by default)
comments - to create or delete comments on a user’s behalf
relationships - to follow and unfollow users on a user’s behalf
likes - to like and unlike items on a user’s behalf
When I make any other type of scope specification besides "basic", I get the following response when the user provides the credentials at the auth URL:
{"code": 400, "error_type": "OAuthException", "error_message": "Invalid scope field(s): basic+likes"}
Any combination of scopes other than "basic" gives the same response.
So, my question are these:
Is explicit auth required in order to specify scopes beyond "basic"??
Do I need to specify response_type=code in order for extended scopes to work?
Is this an Instagram limitation, or is it a limitation of OAuth 2.0?
Thanks in advance.
I just tried with implicit oauth flow with my client_id and scope=basic+likes and it worked. Replace the url below with your client_id and redirect_uri, and try.
https://instagram.com/oauth/authorize/?client_id=CLIENT_ID&redirect_uri=REDIRECT-URI&response_type=token&scope=basic+likes
May be Instagram is not allowing scope other than basic with new client accounts...
The answer here is that YES, scopes can be requested by implicit auth flow just fine. My problem was related to an OAuth component that I was using. The component was silently URL-encoding the value of the scope param, which was rejected by the Instagram auth endpoint. I updated the component (Xamarin.Auth) to accomodate a non-encoded scope param and issued a pull request.
Thanks to #krisak for providing a working URL that I could test.
So I had similar issues regarding the encoding of the + when trying to get permission for multiple scopes (basic, likes, comments). The solution I found was to use spaces between the individual scopes:
In the config/initializers/omniauth.rb file:
Rails.application.config.middleware.use OmniAuth::Builder do
provider :instagram, 'TOKEN', 'SECRETKEY' , {:scope => "basic likes comments"}
end
Unfortunately starting from April 14th 2015 new clients cannot get access for any scope but basic. Official message could be found at the client configuration page:
Starting April 14th 2015, new clients need to request access to be able to post likes, follows, and comments. For more information please read the Developer Blog at http://developers.instagram.com.
The message refers following blog entry: http://developers.instagram.com/post/116410697261/publishing-guidelines-and-signed-requests
Instagram requires personal request to be sent to enable scopes for your application (client ID), but your app has to meet certain conditions described in the blog entry.
i have the same problem i found this solution and works fine
Go to Manage clients under instagram/developer. Then click edit under your app and uncheck Disable Implicit OAuth. It will now work as intended.
Instragram changed this for a reason though, so should probably think twice before going public with your app: http://instagram.com/developer/restrict-api-requests/
At this time, May 2015, YES.
As explained on instagram documentation about authentication:
The Instagram API uses the OAuth 2.0 protocol for simple, but
effective authentication and authorization. OAuth 2.0 is much easier
to use than previous schemes and developers can start using the
Instagram API almost immediately. The one thing to keep in mind is
that all requests to the API must be made over SSL (https:// not
http://).
You first need to register your app here and then, with CLIENT ID provided by instagram, you can do this request:
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=code
Where you have to put your client_id and redirect_uri.
Just for information, in redirect_uri field you can insert also
http://localhost
you must be add "+" between scopes like that is "basic+comments+follower_list+likes+public_content+relationships"