As a beginner I have a few questions that I would like to ask. I am working on an iOS project which is going to be consuming API's such as Twitter and Instagram. I mainly do this to learn how to work with APIs, learn working with HTTP, learn some libraries like Alamofire etc. and at the same time get more familiar with Swift and UI building in iOS in general.
My specific question is about my consumer keys (in this case from Twitter). Similar questions were asked in a lot of places and I have researched them as well, but I couldn't find a definitive answer.
Obviously, I don't want my client secret and client key to be visible in my code and in my github page. I have read about using environment variables for this, but (although I'm not that experienced in all this) it sounds like the secret is still "shipped" with the app, and could be decompiled in some way.
In short, how should I handle the keys and secrets? If I manage to store it safely somewhere and access it from within my code, will someone still be able to see the key and the secret from the HTTP requests being sent to the key provider (e.g. Twitter in this case)?
Also, a small side question is about the callback URL rules I've seen at Twitter (here), where if you use a URL scheme for your app, they require you to use something like this:
myURLScheme-CONSUMERKEY://
How sensitive is the consumer key compared to the secret? Is it safe to use this in the safari view to redirect a user back to the app? Could it be interrupted/stolen by the users of the app?
I hope the question is clear. All remarks and suggestions are really welcome.
Related
I'm trying to develop an open source solution which will be deployed on Raspberry Pi's or similar SBCs. The RPi part is only relevant insofar as it means all the code and app resources need to be publicly available.
The solution needs to read Twitter statuses, as close to real time as possible, and with as little interference from third parties as possible. I found Twitter's Streaming API, which is blazingly fast, and would be perfect for my application – except it requires OAuth. And as far as I can tell, the OAuth mechanism isn't well suited for deployment on users' machines, since it relies on a secret key which belongs to the application owner (the consumer secret).
I couldn't find any easy way around this – the only solutions I could think of are either handling request signing on a central server, or asking each user to create their own Twitter app account. And I find both solutions terribly distasteful.
Do you see any elegant way out?
It turns out this is indeed not currently feasible cleanly with any of Twitter's public APIs; not now, and not in the foreseeable future. Refreshingly, for once we do have proof for a negative: I also asked this on Twitter's own forum, and I was lucky enough to have my question kindly answered by Andy Piper, Global Lead Developer Advocate at Twitter. There you go.
Your app can open a web browser with Twitter's application authentication webpage loaded. When the user enters their credentials Twitter will return a code which they can copy/paste into your app. It's not particularly elegant. Here is a Python example of the workflow: https://github.com/geduldig/TwitterAPI/blob/master/examples/oauth_test.py
I'm working on a fairly basic Alexa skill that, in essence, searches through a specific Twitter feed looking for a hashtag, parses that tweet, and reads it back. The simplest way to do this seems to be using the Twitter API, since scraping appears to be against the TOS.
... crawling the Services is permissible if done in accordance with the provisions of the robots.txt file, however, scraping the Services without the prior consent of Twitter is expressly prohibited.
I've been having some trouble understanding how account linking works, as I've never dealt with OAuth before. I've been trying to follow the one tutorial around, but neither the text or video version were clear me.
Why the need for an external webapp?
...we need an OAuth implementation of our own to make the integration work correctly
What's wrong with the one provided by Twitter? Why can't any issues be fixed within the Lambda method, since the account integration isn't being touched otherwise AFAIK? Isn't having the tokens passed around via the URL a bad idea too? Their example code seems to require that the Consumer Secret be hard coded too.
Enter: “https://alexa-twitter-airport-info.herokuapp.com/oauth/request_token?vendor_id=XXXXXX&consumer_key=YYYYYY&consumer_secret=ZZZZZZ”.
At the very least, their webapp seems to be down for the time being, and it'd be nice to have an option that doesn't require paying money to host another copy.
I've seen this post discussing a Node.js OAuth implementation, but the necessity for such an implementation still escapes me.
I'm trying to create an application that needs to use a backend. That backend will be used to sync an app created (initially) for iOS, macOS, watchOS. Hope to expand after.
Firebase looks like a nice tool to do that, but it only has so many SDK's. I'd like to unify the codebase as much as possible to utilize code reuse.
Seems like their REST API is the way to go: I just create a framework using REST and we're off: https://firebase.google.com/docs/database/rest/start
However, their authentication doesn't seem to support REST.
How do I get around this limitation? What should I do to get a valid auth token that Firebase will understand?
Please keep in mind that I'm not very experienced with web stuff and even after reading a lot of articles, I'm still confused about how to exactly approach this. For example, this user had a similar concern, but I'm not exactly understanding the answer.
Firebase now officially supports REST API:
https://firebase.google.com/docs/reference/rest/auth/
You can query the Firebase Auth backend through a REST API. This can be used for various operations such as creating new users, signing in existing ones and editing or deleting these users.
It's now trivial to create a web app that sits atop Parse.com. Now that I have this webapp, I want to expose parts of it to other developers via an oauth accesible api. So, they can develop an app that lets my site users 'give them permission' via oauth and they can now access the api.
How would I start going about doing this?
Update: After #Mubix response, I felt the following clarification would help
Currently I am accessing Parse from the server via a REST api, to get around any javascript security issues re:api keys etc. So, the api would be served of a server other than Parse. Also, the server code is in javascript / nodejs. I came across https://github.com/jaredhanson/oauth2orize which seems a likely candidate, was wondering how others are doing it and if anyone has actually gone a further step and integrated Parse access.
Hmmm .. Intereesting question!
Legal:
First of all their ToS doesn't seem to prohibit what you are trying to do but you should read it carefully before you start.
Implementation:
While parse doesn't provide feature to build your own APIs you could implement something yourself. You could treat the third party developers as users of your app. And you can use the ACL to control access.
Problems:
I don't see any way to implement oAuth entirely within parse.
How will third party apps access your API? Ideally you would like them to use a REST interface but with the parse.com REST API you won't be able to manage access to different parts of your data.
Conclusion:
It seems like too much trouble to implement the API entirely within parse. I would suggest that you write a thin API layer that takes care of auth and uses parse as the backend. You can use one of the service side libraries available for parse. eg. PHP Library, Node Parse.
On my current project we planing to integrate Facebook for authentication. The site use different domains for i18n, sitenameineng.com sitenameinswe.se and so on.
Facebook only allows multiple domains with the same base URL and that's where the problems begin.
I could put up a new project for each language, but it feels incredibly unnecessary. What would be the best solution?
The only solution I can come up with is to create a new Facebook app for each language and then change the facebook app id and secret in my project depending on locale or is there a better solution?
If there is no better solution, how should I do to put app id and secret depending on locale?
Thanks
What about creating something like a proxy app which provides an API for all your domains to work with?
Say: proxy.sitename.com contains the SDK, authentication, database handling, and redirects to the proper website. You can then make requests to your proxy which, in turn, calls the Facebook API endpoints using the provided access token. Sure, this can result in slight perf hit, but this is probably the best way to solve this.
Considering the nature of your project, you might also want to consider: https://developers.facebook.com/docs/internationalization/