Actually, if you look at existing apps that authenticate through Twitter's oAuth for example, you can see that, indeed, a browser is required to grant access to the account. However, both iOS and Android have an option to launch a browser window within an application itself.
So usually when the users clicks "login through twitter", you'd fire up a browser screen inside the app that will load the Twitter authentication page. This page is already optimized for mobile so it will simply show the button to authenticate (or the login fields if the user isn't logged in to twitter yet). Then you have your app setup to close the webview when a succesful request is made, and log the user in.
Facebook is a similar example, except that in this case, facebook requires the app to actually launch the Facebook app, which will handle the authentication and automatically switches back to your app when the authentication is succesful.
After two days of trying to figure out why my app suddenly broke (it used to work before), I found your reply here and I have the exact same issue!
Before this worked:
haml
- for project in @projects.models
%a{ href: "/project/#{project.get('slug')}" }= project.get('name')
But after some more working on the app, and updating gems (which I suspect broke things), I had to replace it with this to continue working:
haml
- for project in @projects.models
%a{ href: "/project/#{project.get('project').slug}" }= project.get('project').name
I suspect something changed in a recent Backbone.js update or it has something to do with Rails' include_root_in_json options (but I tried both false and true, no dice).
I sometimes wonder if Ryan has a way to check the most searched google queries related to Rails (does Google provide such a feature?) or that he simply checks the search queries on his site. It's way too often that I've seen Ryan releasing tutorials that I or at least a few viewers where actually looking for in the past weeks.
I too had an issue with this, you have to do some magic converting the param to a correct JSON format, but the easier solution (at least for Rails) is to use the form method to send the data, instead of the default json method.
Simple, add a conditional statement to the line where you include mercury.js. Without this file Mercury never loads, so something like this would solve your issue:
Ruby
<%= javascript_include_tag('mercury') if current_user %>
Actually you are right, mercury-rails does have a few conventions (using Formtastic and Paperclip), but Mercury (the editor) doesn't use any of these dependencies, it's only the Rails backend that uses it. But you are free to use any backend you want. The forms for the modals can be customized so you can do without both Formtastic and Simpleform if you want, and I myself use Carrierwave with Mercury without ever lookign at Paperclip.
So I don't see how it is annoying that Mercury includes a few simple examples/conventions for you to get started without almost any coding on the server side.
I am a little late to the party, but I would recommend looking at ranked model, it handles ordering a lot nicer than the (old) acts_as_list.
Here's a snippet from the Github project page:
This libarary is written using ARel from the ground-up. This leaves the code much cleaner than many implementations. ranked-model is also optimized to write to the database as little as possible: ranks are stored as a number between -8388607 and 8388607 (the MEDIUMINT range in MySQL). When an item is given a new position, it assigns itself a rank number between two neighbors. This allows several movements of items before no digits are available between two neighbors. When this occurs, ranked-model will try to shift other records out of the way. If items can't be easily shifted anymore, it will rebalance the distribution of rank numbers across all memebers of the ranked group.
Perhaps your problem is related to Matt-Bishop's comment?
For anyone who is still using ruby 1.8.7 for rails 3.0.5
SecureRandom.urlsafe_base64 will generate a method not found error. I used SecureRandom.hex as a substitute and it worked. Just thought I'd share in case this helps anyone...
Or use Gabe Kopley's solution:
Nothing wrong with hex, but if you want base64, you could do this:
Is there then a reason why you didn't use cookies.permanent.signed for the auth_token instead of cookies.permanent? It seems you can chain them and I can't find any drawbacks from using this.
Hey Ryan, thank you for the explanation. That makes a lot of sense. Still though, after reading your comment and seeing the episode I personally would prefer to go the UsersController way, having a special "reset_password" action.
I haven't tested this yet so I don't know if this is correct, but I guess this is all that is needed to get it working in the routes, which isn't all too complex and requires only three extra lines (two if you already have the :users resources):
routes.rb
ruby
resources :password_resets
resources :usersdo
get "reset_password", on::memberend# /users/:password_reset_token/reset_password
or as an alternative:
ruby
resources :password_resets
get "reset_password/:id" => "users#reset_password"# /reset_password/:password_reset_token
UsersController
ruby
defreset_password@user = User.find_by_password_reset_token!(params[:id])
if@user.password_reset_sent_at < 2.hours.ago
redirect_to new_password_reset_path, alert:"Password reset has expired."elsif@user.update_attributes(params[:user])
redirect_to root_url, notice:"Password has been reset!"else
render :editendend
Nice to see you active in the comments section as well. Wish you dropped by a little later to allow me to add this question to my reply, but here goes:
In the episode at 8:13 you talk about the URL the user uses to reset his/her password and that it isn't the most elegant RESTful route, but "it will work for us here".
I love (almost) all the screencasts you publish, and I watch every one of them at the start of the week (go self employed!) but I've noticed you've taken these "quick and dirty routes" a couple of more times in the past, and every time I hear you say that I get a nasty feeling, that I am following along writing some great code, and suddenly we make a shortcut and you leave me (us?) high and dry, wondering what I should do to make it actually be the best RESTful way to handle this.
On internal code (code that is never shown to the outer world) I don't mind quick'n'dirty techniques from time to time, if it helps me move on so I can come back to it later, but crucial parts (database layout) and code that is shown to the outside world (routing), I like to make it as good as possible.
Now this isn't criticism, instead I hope you take this as positive feedback. And perhaps you could elaborate on ways to improve the route at 8:13 for this screencast.
Thank again, and obviously we all have to try things ourself, so I'll definitely be trying to improve that piece of code.
Great episode. And I too want to put my vote down for more "from scratch" episodes.
I love the gem community and all the Github repos out there, and while I sometimes use these screencasts to find new "gems" amongst the gems, I mainly use it to learn and follow along while I write the same code, in my own style.
Who says you need to use Jquery? or Coffeescript? or Haml? or Sass? or Git? or Activerecord? Or ...?
Rails is modular, in fact, I think it is one of the most modular frameworks out there.
Yes, rails comes "packaged" (as in, it has a few extra lines in the Gemfile) with some defaults, it's an opinionated framework, and that's one of the reasons why it's gotten so big so fast, but all that does is make it easier for beginners to jump in and start coding.
Is it really that hard for you to type a few extra characters when you create a new app?
Rails new myapp = Jquery, Cofeescript, Sass, Erb, Activerecord, Test Unit, Git
Rails new myapp -OGJT = ... none of the above, go figure!
Actually, if you look at existing apps that authenticate through Twitter's oAuth for example, you can see that, indeed, a browser is required to grant access to the account. However, both iOS and Android have an option to launch a browser window within an application itself.
So usually when the users clicks "login through twitter", you'd fire up a browser screen inside the app that will load the Twitter authentication page. This page is already optimized for mobile so it will simply show the button to authenticate (or the login fields if the user isn't logged in to twitter yet). Then you have your app setup to close the webview when a succesful request is made, and log the user in.
Facebook is a similar example, except that in this case, facebook requires the app to actually launch the Facebook app, which will handle the authentication and automatically switches back to your app when the authentication is succesful.
I third/fourth that. OAuth2 security for your API please.
Same OS & Browser, same results.
After two days of trying to figure out why my app suddenly broke (it used to work before), I found your reply here and I have the exact same issue!
Before this worked:
But after some more working on the app, and updating gems (which I suspect broke things), I had to replace it with this to continue working:
I suspect something changed in a recent Backbone.js update or it has something to do with Rails'
include_root_in_json
options (but I tried bothfalse
andtrue
, no dice).So we shouldn't use Bootstrap because the Twitter guys chose to omit semicolons where possible? Really? Or did I miss the
/s
somewhere?I was actually wondering the same. I found something here that says it should show the time:
But it doesn't work for me either, so I simply removed it (not that I would want the time shown on each and every command line).
I sometimes wonder if Ryan has a way to check the most searched google queries related to Rails (does Google provide such a feature?) or that he simply checks the search queries on his site. It's way too often that I've seen Ryan releasing tutorials that I or at least a few viewers where actually looking for in the past weeks.
Anyway, can't complain either way!
I too had an issue with this, you have to do some magic converting the param to a correct JSON format, but the easier solution (at least for Rails) is to use the
form
method to send the data, instead of the defaultjson
method.Simple, add a conditional statement to the line where you include mercury.js. Without this file Mercury never loads, so something like this would solve your issue:
<%= javascript_include_tag('mercury') if current_user %>
Actually you are right, mercury-rails does have a few conventions (using Formtastic and Paperclip), but Mercury (the editor) doesn't use any of these dependencies, it's only the Rails backend that uses it. But you are free to use any backend you want. The forms for the modals can be customized so you can do without both Formtastic and Simpleform if you want, and I myself use Carrierwave with Mercury without ever lookign at Paperclip.
So I don't see how it is annoying that Mercury includes a few simple examples/conventions for you to get started without almost any coding on the server side.
I am a little late to the party, but I would recommend looking at ranked model, it handles ordering a lot nicer than the (old) acts_as_list.
Here's a snippet from the Github project page:
Perhaps your problem is related to Matt-Bishop's comment?
Or use Gabe Kopley's solution:
Is there then a reason why you didn't use
cookies.permanent.signed
for theauth_token
instead ofcookies.permanent
? It seems you can chain them and I can't find any drawbacks from using this.Actually the UsersController should be like this, the above is the update action, which should stay the same:
Hey Ryan, thank you for the explanation. That makes a lot of sense. Still though, after reading your comment and seeing the episode I personally would prefer to go the UsersController way, having a special "reset_password" action.
I haven't tested this yet so I don't know if this is correct, but I guess this is all that is needed to get it working in the routes, which isn't all too complex and requires only three extra lines (two if you already have the :users resources):
routes.rb
or as an alternative:
UsersController
Nice to see you active in the comments section as well. Wish you dropped by a little later to allow me to add this question to my reply, but here goes:
In the episode at 8:13 you talk about the URL the user uses to reset his/her password and that it isn't the most elegant RESTful route, but "it will work for us here".
I love (almost) all the screencasts you publish, and I watch every one of them at the start of the week (go self employed!) but I've noticed you've taken these "quick and dirty routes" a couple of more times in the past, and every time I hear you say that I get a nasty feeling, that I am following along writing some great code, and suddenly we make a shortcut and you leave me (us?) high and dry, wondering what I should do to make it actually be the best RESTful way to handle this.
On internal code (code that is never shown to the outer world) I don't mind quick'n'dirty techniques from time to time, if it helps me move on so I can come back to it later, but crucial parts (database layout) and code that is shown to the outside world (routing), I like to make it as good as possible.
Now this isn't criticism, instead I hope you take this as positive feedback. And perhaps you could elaborate on ways to improve the route at 8:13 for this screencast.
Thank again, and obviously we all have to try things ourself, so I'll definitely be trying to improve that piece of code.
Great episode. And I too want to put my vote down for more "from scratch" episodes.
I love the gem community and all the Github repos out there, and while I sometimes use these screencasts to find new "gems" amongst the gems, I mainly use it to learn and follow along while I write the same code, in my own style.
Thanks again!
Who says you need to use Jquery? or Coffeescript? or Haml? or Sass? or Git? or Activerecord? Or ...?
Rails is modular, in fact, I think it is one of the most modular frameworks out there.
Yes, rails comes "packaged" (as in, it has a few extra lines in the Gemfile) with some defaults, it's an opinionated framework, and that's one of the reasons why it's gotten so big so fast, but all that does is make it easier for beginners to jump in and start coding.
Is it really that hard for you to type a few extra characters when you create a new app?
Rails new myapp = Jquery, Cofeescript, Sass, Erb, Activerecord, Test Unit, Git
Rails new myapp -OGJT = ... none of the above, go figure!