Sign in through GitHub

Please read for an updated status on RailsCasts:

Learn more or hide this

n1kopuf@l's Profile

GitHub User: nicholaspufal

Comments by n1kopuf@l


I would really like to see that also.

Btw, don't you guys think that many of these methods could be extracted into a Presenter?

Since they all affect the presentation of the information (they do not modify the data itself), I think would be much better to see it on a Presenter.

The same is not valid to Tag/Category creation, of course.



I made my wi-fi public when I tested.

Can it have something to do with OS (I'm on Lion)? I'm not a big understander about networks, but with the wi-fi public shouldn't I see it?

Of course, when doing from my computer I'm able to see that cookie session info, but even that way, when using cURL, I was not logged in. It just redirected me back to the sign_in path.

Any ideas of what could be wrong? I'm just following the same steps.


Thanks for this episode. I never was really aware of this issue.

However, I tried to reproduce the steps in my local network using a Rails app that was already deployed, and the cookies didn't appear anywhere when using tcpdump.

I tested it using my wi-fi network, and 2 different machines (mine and another). When I tried to login using the other machine, none of that info appeared in tcpdump.

I'm using Devise for the authentication.

When I tested it in my local machine, then I could reproduce the vulnerability and see all the cookie information.

Am I missing something? By what I understood, shouldn't I be able to see it when in my local network (and not only localhost)?


Thanks a lot for this :)

Ryan, do you by any chance have in mind doing an episode similar to this, but focusing also on polymorphic associations, or associations in general?

Maybe it's just me, but I find very difficult to work with Arel when in those situations. Specially polymorphic. The solution is always do SQL by hand.


After this Railscast I found out that internally Rails is handling the build of the associated object when needed. It seems that this behavior has in fact changed.

The only thing I needed to add is a instantiation of my join model to the action 'new'.

I have a Proposal model which can have many Product through a join model called ProductEntry.

In the action 'new' from my ProposalsController I simply added:

   @proposal.product_entries <<

This is just to display the form field when no ProductEntry is available yet, which is always the case when I'm creating a new Proposal.

When I go and edit a Proposal, Rails automatically instantiate all ProductEntry that are associated. If I edit any of those ProductEntry (such as the quantity attribute that I have), it simply works too.


How this would work when the models are associated via a has_many :through association?

I'm trying to follow the same steps, however nothing is displayed in my form.

I remember that the first episode regarding this topic used to build the objects in the controller, e.g., so that they would be made available in the view. I found really weird that this wasn't mentioned this time.

Did that behavior changed in Rails?

In order to make it work with has_many :through I need to build "by hand" the associated object in my controller?

Thanks :)


That's the why Ryan suggests the "h" method. It's an easier way to access the @template attribute.

That way you could do something as:

  def name
    handle_none do
      h.link_to(, h.user_path(user))