Chris Oliver

Thanks Stan! :)

I believe with multiple files (at least for separate things) you just say

class User
  attachment :photo
  attachment :resume
end

You may need to modify the Javascript somewhat so that it can tell the difference between the two. That likely is worth doing another episode on, some form of refactoring Javascript to handle this better.

The thing they don't handle right now is uploading multiple files (like User has_many :photos) but that should be coming soon. At least after reading that thread, it seems it should be easy for someone to implement it.

In that case, I would stick to just a string column on the User model for role. That way it can only store one value (and you can add more later easily). No need for a join table here because your User will just contain the role.

# role :string
class User
  def user?; role == "user"; end
  def admin?; role == "admin"; end
  def superadmin?; role == "superadmin"; end
end

You can create some helper methods like that to determine what type of user they are.

Then to restrict who can change that, you can update your controller's strong params code for superadmins to add the role column as allowed for editing. The other types of users won't allow that field, so they can't change user's roles.

You can do that with Pundit pretty easily. First you'll create the policy for the User model and then you can have your controller ask the Policy which params are allowed:

# app/policies/user_policy.rb
class UserPolicy < ApplicationPolicy
  def permitted_attributes
    if user.superadmin?
      [:first_name, :last_name, :role]
    else
      [:first_name, :last_name]
    end
  end
end

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def update
    @user = User.find(params[:id])
    if @user.update(user_params)
      redirect_to @user
    else
      render :edit
    end
  end

  private

  def user_params
    params.require(:user).permit(*policy(@user || User).permitted_attributes)
  end
end

Yeah that's a good idea to do self signed for staging since you can trust it. Nobody else will really be using it so that should work totally fine (and cheaper!)

You're definitely right. Chrome is redirecting to SSL but not Firefox. Weird. I'm going to force_ssl from now on. Thanks for the heads up! :)

I usually have a separate app and database for staging. GoRails currently doesn't have a staging app but it needs one soon. Separate servers are good, and you can copy production data into the staging database to test against real(ish) data. Just make sure that things like API keys don't match production ones so your test users in staging don't get emails, etc when testing. ;)

Glad you got it working! :)

It sounds like your variable that you called ".likes" on was a nil. May need to double check that the find is grabbing the post (or whatever model) is returning the right object.

Hey Alex,

The easiest thing (if you're using a string column like I did in the episode) is to just do a dropdown because each option's value is text.

Check boxes make sense if you've got a join table and allow each user to have multiple roles.

Instead of a dropdown, you could do radio buttons for a bit more visible UI:

f.radio_button(:role, "user")
f.radio_button(:role, "admin")
f.radio_button(:role, "superadmin")

Does that make sense?

Check your /home/deploy/APP/current/logs/production.log file for the errors. That's the error page from Rails so Nginx is set up properly but Rails isn't just yet.

I'm using Nginx to redirect to https so it shouldn't allow you to use it over HTTP (aside from the first request which redirects you). I think it's wise to also do force_ssl with Rails as well so you have a backup to enforce that.

I don't think I have force_ssl set (but I should), although I can't seem to reproduce accessing GoRails via only HTTP except with curl. Are you able to view GoRails without ssl in your browser?

Yep. You can set it up to do a git push like Heroku does, but I've never set a server up that way before so you'll probably need to do some digging to figure out how to do it. Check out this: https://www.digitalocean.co...

I'd recommend reading through this for a bunch of SSL related information and an example config: https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

I just purchased my SSL cert from the same place I registered the domain which you can usually do. You'll need to just upload that to the server and configure it to load the cert and key from that process. Usually they give you some instructions on how to do that as well.

Here's one where he buys the cert from Namecheap and configures it: https://aralbalkan.com/scribbles/setting-up-ssl-with-nginx-using-a-namecheap-essentialssl-wildcard-certificate-on-digitalocean/

Not really. The only thing that will change is querying for the nested object and adding likes to it.

Your controller would do something like:

@course = Course.find(params[:course_id])
@lesson = @course.lessons.find(params[:id])

And then as long as you have your likes association on the Lesson model, you should be good to go.

If you're shooting for a complex setup, Rubber is probably good. This is just a simple Rails App and MySQL or Postgres instance on the same server.

Yep, pretty much the same thing aside from they connect you differently with .pem keys instead of a password to login initially. May also have to open up the ports to the outside world so you can server HTTP requests.

If it's in reference to your Post database model (That's my guess) then you want to reference singular "Post" and not plural "Posts" in your controller. Pluralization can get you easily with Rails. :)

So the two files database.yml and secrets.yml work similarly. Both files are used to store private information (passwords, API keys, etc). You normally don't want these in your git repo. You can keep examples in the repo so that people can quickly set it up on a new machine, but that's about it.

When you don't have the files in your git repo, that means everyone who clones the repo to their development machine has to create the database.yml and secrets.yml and configure it to point to their database.

Production works the same way. You've got a different database and different passwords / API keys that you need to use there so you create those files manually on the server just like you did on your local machine in development.

If you run your own server and deploy with capistrano, you put these files in a shared directory. The deploy script symlinks this file into the Rails app so that every deploy gets pointed to the correct database and secrets files. No need for environment variables here.

Heroku makes this a bit different than if you do Digital Ocean, AWS, etc. There is no shared directory so you actually set environment variables with heroku config. They overwrite your database.yml and you don't get the same benefits of using secrets.yml since they are already in ENV.

ENV is sometimes tricky to set up when deploying your own app. Apache, Nginx, and all the other web servers configure environment variables differently. That's why they introduced secrets.yml so you don't have to mess with configuring all these different services and your application can simply handle it.

Does that clear things up?

Your best bet is to probably try following these steps. Homebrew should take care of getting everything installed properly for you.

Interesting. I can't think of much except for maybe having a typo somewhere.

Since they are reads, I think that so long as your database server can handle it, it doesn't matter how many connections read from the same table. Reads don't lock the table/row like writes do since a read cannot cause data loss. You shouldn't experience any loss of speed if many things are reading the same table.

Hey Jon,

Not yet! I've been busy with the holidays but I plan on starting to cover this in the next week.