Chris Oliver

I think if that all happens server side, you should be fine. Since the session is encrypted, storing the token should be safe there. This is basically how login with mobile apps works. Make sure you're sending the token over SSL so it's not publicly accessible over the network and it's usually best to set an expiration on tokens if you can.

Devise is its own authentication system. If your registration API is in the PHP app, you won't be able to use it and you'll need to write your own code to handle that instead. Devise doesn't talk to APIs for authentication, just the database.

If you're putting the user authentication in the new Rails app, then you could use Devise.

Make sense?

My two suggestions would to either put this in the index or in an action called active with it's own route.

1. You create the active action with a route. This will let you create a separate view and render a different HTML template.

2. You just add it to the index by checking a query param:

def index
  @projects = policy_scope(Project)
  @projects = @projects.active if params[:filter] == "active"
end

Lots of different ways you could implement this, but the simplest example is just adding a scope to the Relation that you are rendering based upon a param like filter. This is nice for adding more filters in the future which you might want to do as well.

You might check out this gem: https://github.com/magoosh/...

Yeah that's what I would do. Remember to have this only: [:edit, :update, :destroy] so that it doesn't override your show action's lookup which is normally set in a before_filter as well.

The important part is making sure you edited your .bash_profile and added rbenv to your PATH. That will allow it to find the rbenv ruby before the system ruby.

This is the important line from above (after you installed rbenv)

echo 'if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi' >> ~/.bash_profile
source ~/.bash_profile

They way you could solve the authorization problem is by updating your Edit/Update/Destroy actions to use current_user.books.find() instead of Book.find(). That will scope it to only the ones that user owns so they cannot edit other user's books.

This is awesome and I'm definitely going to check it out tomorrow!

If you're authenticating between different apps, then you want them to share the same secret key. The cookie_store is signed with that key (I believe) so you would simply want to modify both apps to use the same SECRET_TOKEN in your application.yml files in production. That should do the trick (along with setting the domain on the cookies in the other post you mentioned).

There is basically no difference in your workflow other than SSHing in for running the server. Like I mentioned, the folder is shared between the host and the VM guest. You have to install all the tools inside the VM to run the app, but since it's shared you can edit in either place. You debug your app exactly like normal through the terminal. It just happens to be inside SSH to the VM, but there is almost no difference.

I agree! It was also awesome to meet you in person Jared!

A combination of decorators and the null object pattern can go together quite well. Curious to hear how it goes for you!

Awesome, glad you liked it! :) Definitely want to cover more of these design patterns and their practical uses.

That turned out really clean! I'm glad you guys got it working. Airpair is pretty great.

Yes, the none method is super helpful for situations like that. I'm really glad they added it.

Definitely. You can use this a bit too early and it just is more painful than anything. The example of the navigation is bad because right now, I'd rather have the if statement, but in the future as it gets way more complex, null objects would make more sense.

There's certainly a balance to find when applying this (like any pattern).

Awesome! Glad that worked. The error came from trying to install a gem into system ruby. Some people will tell you to use "sudo" to fix it, but that's not fixing the real problem which was that it was using the wrong version of Ruby.

Good rule of thumb is that you should *never* use "sudo" when working with Ruby. It's always a sign you're doing something outside of rbenv and something's configured wrong.

Fingers crossed the rest of your setup goes well!

It sounds like you aren't using the proper version of Ruby and it's trying to install in your system Ruby. Make sure you didn't miss any commands and try restarting your terminal. When you run "which ruby" you should get something like "/Users/chris/.rbenv/shims/ruby".

Most of my projects are private and I put them on Github (paying for private repos) and you could easily store them privately on Bitbucket. In either case, your Capistrano URL will securely authenticate with Github or Bitbucket using your SSH key to check out the code. It logs in using that so you don't need to use a password to clone the code on a deploy.

Always the file named Gemfile in the root of your Rails application. It's the defining list of dependencies for each Rails app. You save it in each app so that all of them can use different versions without fighting each other.