I am working on an app that will require the user to authenticate against yelp and foursquare, and potentially facebook and pinterest( a lot of things ).
I started by persisting all this info locally on disk, but then thought this might be insecure, then I went to the next scenario which is to have a collection on the backend that has all configs needed that every time on load I go and get it.
Anyhow, I was wondering whether people have a way to gut out all the configs related to this kind of info from the app, and maybe put it somewhere or whats considered best practices for this scenario?
An example of these configs would be Oauth Token from Foursqaure, yelp, facebook, and whatever other api I need to connect to.
Related
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 have read that when storing the app_id and app_secret, you do not want to directly add them to the code in your initializer. That there are security vulnerabilities. Solutions like Heroku allow you to create env variables for something like this, but I want to understand what the vulnerabilities really are.
If these keys were written within my initializer code, committed to git, and pushed to a private repo on github, and deployed using Heroku. What security vulnerabilities exist?
The first concern we, as developers, think when securing our app is some hacker from the outside world being able to get data that it should not be able to get direct from our app. We should then get our app rock solid, right?
Well, even that being nearly impossible, there are at least two more ways besides a direct vulnerability on your app:
Social engineering
Enterprise network vulnerability
Social engineering: Must be the most hard leak to close, people ability to detect they are being taking into it will vary over time, and will depend in a lot of things(mood, money, ...). You're just a phone call from leaking information
Enterprise network vulnerability: The chain is as safe as its weakest link. If you make your app the unique 100% unbreakable in the know world, some still can be able to use an open door on your company network to get credentials from your app. This method is often used with social engineering, first gaining access to the intranet to proceed to your application.
To mitigate those vulnerabilities you should close as much as possible the access to your credentials, to the point that even you can't get them easy.
Adding production credentials into the repository will lead to more people being able to see it and easier to a hacker get access to it(even just sniffing your wifi network).
Putting your credentials into env vars will not be a perfect solution, but at least you will decrease the amount of people with access to it(#1) and it will transit a lot less(#2).
There is no way to being 100% secure, but you should work hard to make it as close as you can to mitigate possible flaws.
I a thinking of creating an iPhone/iOS app that would include a feature where one user could create a list of words and then save them to their account on a server. Also (and this is very important), the user could share their list with other users by giving them permission.
So my question is, how can I go about creating such a server? For right now, I have a home computer (running Windows XP that just stores data for my music system) which I can use to host the server. I am also open to the use of other online storage services like Google Drive or Dropbox (I can't remember if Amazon does anything like that). However (and I know this may complicate things a bit), but at least for now, I want/need to stick with free services/options.
Just to recap, the key features that I am looking for are:
create users/accounts (on the server)
eventually I may [try] to incorporate the use of other services to log users in like with their email account, OpenId, etc.
the ability to access (log in to) the server (with credentials) from my app
the ability to send/receive data between the server and my app
the ability to share data between users
I know this is a lot to ask for, but if anyone has any suggestions or can get me going in the right direction, it would be much appreciated.
The basic setup would be as follows:
Backend: Database (MySQL), Web server (Apache), with server side scripting (PHP).
Client: iOS device with developed app.
Communication: use HTTP client/server model, communicating with something like JSON.
This is much the same setup as a web server, but instead of serving html/css/javascript etc the results will be JSON.
As far as implementing specifics such as login in, and sharing data between users, this is purely dependent on your implementation. This is not trivial, and not something that can be easily stated in a single post.
Hope this helps.
You could build your own webservice in PHP, Ruby or Python. If you do so I would recommend building a RESTful webservice (http://en.wikipedia.org/wiki/Representational_state_transfer) and then use RestKit (http://restkit.org/) to handle the data in the iOS app. Especially RestKit's CoreData integration is nice in my opinion.
Another solution would be using a service like Parse (https://parse.com/products/data). The first million or so requests per month are free but after that it could get pricy. I personally have not tried it so I couldn't tell you if it is any good.
I'm planning to build a group of several Rails applications on Heroku, and I want to share accounts, user data, and maybe some other information between these applications and the "main" Rails app. What would be the easiest and most effective way of doing this?
I've heard that one way of doing this is to make all the applications share the same database, but I'm not sure if that's really the best solution in my case since I only need to share some information between these apps. Another thing I've considered is using the CAS protocol, but that only seems to handle authentication (I can't use it to get user's names and email addresses). Suggestions?
Here's how I'm considering doing this.
Create a master app with user authentication.
Have each sub-app do omni auth with the master app.
Then the master app will house all the user data, and the sub-app will get the authentication info necessary plus the user data. I haven't figured out how to make sure that new user data will be saved in the master app, but it seems like you would just send the user to the master app, then have them returned once they've entered the data.
Any suggesting from you Rails experts out there before I sink a week into doing it this way.
I'm building a standalone couchdb application. These are called couchapps. The idea is that the database itself is served on port 80 and returns HTML and works as the actual website. This is a very powerful idea and I'm entirely amazed by this new concept of having your code live inside your database.
But I'm having some issues with user registration. The one built into couchdb allows for cookies to be set and makes it really easy to plug it into your website. But there's several quite important things missing that my app requires in order to say that it has a "proper" user registration system.
There's no signup verification. No email is sent, no captcha is displayed. This means that anyone could spam your _users database and create as many new users as they please.
If a user forgets their password there's no facility to help them recover it.
Any idea how I could overcome these issues without doing any hardcore Erlang development at a lower level (not an Erlang guy)? It would also be great if anybody knew if I could be using OAuth to authenticate against Twitter or GitHub accounts and have that integrate seemlessly with how couchdb data is handled (inside validate_doc_update functions).
Thank you
While the built in user database can work, I would not recommend it for the workflow you describe. Here are some other options:
Browser ID
I would really recommend using BrowserID. IrisCouch has provided a plugin to couchdb here:
https://github.com/iriscouch/browserid_couchdb
This will take care of the normal registration workflow.
If you want to take it a step further and have your users "Fairly Anonymous", you can follow the example of this couchapp called "Mingle"
https://github.com/thedod/Mingle
Twitter Integration
Max Ogden's "DataCouch" project has a log in via twitter, although it is using some Node external processors to make it work. See here:
https://github.com/maxogden/datacouch/blob/master/processors/auth/twitterauth.js
Facebook integration
https://github.com/ocastalabs/CouchDB-Facebook-Authentication
OpenID
https://github.com/mcaprari/couchdb-openid
I dont think you can use the oauth purely with Couch, as this post suggests:
http://bennolan.com/2011/01/11/couchdb-oath.html
so the closest you will get there is following what Datacouch has done.
Hope these suggestions help.