I have built an app in Rails and hooked up SSL through expedited SSL and Heroku. I implemented Facebook omniauth for users to log on as well. When using the standard log in method the connection is indeed secure with a green lock showing in chromes browser window. When users log on via Facebook omniauth though, the have a lock with a caution symbol, and the explanation of:
The connection is encrypted and authenticated using AES_128_GCM and uses ECDHE_RSA as the key exchange mechanism.
Since I am just learning, I do not know if I should be concerned about this or not. My gut says to not worry about it, but it still makes me feel uneasy.
The problem as I was using http: instead of https: inside of a model when grabbing user images. Simple oversight.
Related
I have a Rails 5 (Ruby 2.3.3) app with OmniAuth (1.6.1; omniauth-oauth 1.1.0) and omniauth-twitter (1.4.0). When a user is directed to Twitter for the OAuth flow, they see the following error after tapping the "Authorize application" button:
Whoa there!
There is no request token for this page. That's the special key we need from applications asking to use your Twitter account. Please go back to the site or application that sent you here and try again; it was probably just a mistake.
The most unfortunate problem about this error is it doesn't happen locally—I have a an identically configured app in Twitter's app management console, save for a different URL (127.0.0.1 for the local app, a Heroku URL for the server).
Additionally, we have other OmniAuth strategies that work without issue locally and in production.
Verify that your system clock is set correctly and that all of your keys are entered correctly. Ensure you're using the right paths (api.twitter.com/oauth/*) and make sure that you're actually sending a request token to the oauth/authorize page and not an access token.
I have a website that users can log into to see their account info.
I would like to build functionality into my iOS app that allows them to log in and see their info in the app. The usernames and passwords are stored in a SQL database.
How can I authenticate the username and password the user types into the app with the database?
If you have better atuthentication system in your web..
then i would prefer you to use the WEBVIEW for your login page. and continues the other using the normal app flow.
there are lot of tutorials for creating username and password login Function in IOS. i dont know whther you are basic or new progrmmer. But try this you may get some idea.
http://www.youtube.com/watch?v=HrZR2SyeoSk.
You can go with JSON serialisation, if you experienced to load data from server.
There are multiple ways you can go about this but at the end of the day you need an endpoint for your iOS application to talk to your web server. This can be done with a TCP connection (little more complicated) or with a RESTful HTTP API endpoint which is generally the way most developers will go.
To get you running up and quickly on the client side have a look at AFNetworking to do the heavy lifting on your HTTP requests. You will then need a URL on your website that the iOS application can query. Abstract things to keep your API on a different subdomain, say for instance by creating a subdomain to handle your API requests. A login example could look like this
http://api.mysite.com/login
For a PHP based REST API here is a tutorial for you, PHP API or you could use a Node.js framework such as Restify
The general practise is to use JSON encoded data when sending requests back and forth from the server, iOS 7 has built in JSON encoding/decoding, node and PHP also have pretty good support.
Once you are able to send and receive HTTP request from your iOS device to your web server it is just a matter of checking the username and password match up on the server side (seems you already know how to do this?) to the ones in your database and sending back a authentication BOOL and option error message if failed.
To my understanding creating a smartphone apps based on a site is to simply create an API for the website and to output the data in XML, JSON. In my case JSON has Ruby on Rails has it built it in it. In theory all I have to is to read the event.json page and read the attribute and on phonegap to read it and build a logic from it.
However, in my phone app, I would like to allow user to log in before entering and in fact on the web-base I am using the devise gem to manage my user management. How am I supposed to allow user to log in from device using phonegap? Should I read an API JSON that showcase all users but then that may cause a lots of security issues, is there a device documentation on that specific issue, or should I scrap device and just make an authentication system from scratch?
Devise provides for an auth-token to be used for login. This works well with JSON APIs as you can set a header to include the auth-token to identify the user. Your login form would just be responsible for getting an auth-token from valid credentials. SSL can help to secure this information on the wire.
I created a Gem based on rack_iphone which store the session
in the localStorage and and upon opening a application from a home screen shortcut
the application take the cookie if present from the localStorage and the sent it to the server
Hope this work for you
I'm working on an app using facebook & oauth. The app lives inside a facebook canvas, and the authentication is done server side. The app is done w/ Ruby on Rails 3.2, using Koala for dealing with the api (and mongodb as backend, for what it's worth), and hosted on heroku.
So, I supply the heroku url as redirect_url for the callback. Which makes the user go out of the canvas after the authentication, and well, I want it to stay inside. I read a few threads about this that suggested I redirect to the canvas url with js once the authentication is done. I did that, but now it seems that my session token is never set, and the user goes through the auth flow every time he tries to see a non-public page (which means he loops on the welcome page, having an "invisible" exchange with facebook each time).
I don't really get what I'm doing wrong here, so any help is welcome. If you need more informations, just ask.
Thanks for your time!
So I found what was my problem : the page my canvas pointed to was a "public" page, and did not handle anything authentication related, meaning it didn't parse the signed_request, or anything else. I ended up setting a special endpoint for the canvas in charge of handling the signed_request logic, and now it works as one would expect.
My goal is to build a standalone RESTful Rails 3 service that communicates with a Rails 3 web application via ActiveResource JSON and an iPhone application via iOS 5 native JSON. I have each running so that a single table of data is being exposed in the service app and that can be called and rendered via both a Rails app and the iPhone app.
My question is around authentication and something that can be reusable for both the web application and the iPhone app or in the future an Android app.
From the research I have done on this site, it seems HTTP Basic would work for both, however I would be unable to properly logout a user on the web side like sessions or cookies could and I have the browser login form to deal with. If I use sessions, how would that translate to setting up authentication on the iOS side of things?
This project is a code learning exercise, so I am hoping for implementation or architectural guidance rather than simply implementing Devise or Authlogic, etc.
It sounds like you're conflating at least two problems.
The first issue is authentication: you need to determine if the user is who they say they are. For authentication, you can do basic auth. You could also use client certs, though that's probably not what you're looking for.
The second thing is session management: First, you can do basic auth on each page request and store the session state in the database, but you're right about not being able to log the user out, as the browser will cache the credentials.
You may want to consider a login page that requires basic auth and shoots back a cookie to do session management. All other pages don't require basic auth, but give a 401 unauthorized if the cookie isn're present. Or you could redirect. The iOS client code will have to know to call the login page first to get the cookie and then use it after that. Logging out is deleting the cookie.. hrmm, but the browser will still cache the basic auth credentials.
I'm thinking the only way you're going to get what you want is to have a form-based auth for your web users (to allow them to log out and log in as someone else), and a basic-auth based system for iOS users. As a result of both authentication mechanisms, return a cookie that has to be used for all other pages.