Yi Mei Wang

Might be a stupid question, but it's worth asking... Have your tried different a browser on your machine?

Something else worth trying. Go to your Developer Console > Application > Clear site data. Could be some cached CSS that happened on your machine during development

Hey Chris, I was contemplating creating a new method, but I decided to override the link_to instead because I did not want the burden for the team to have to constantly remember to use a new method instead of the usual link_to. My intention was to make link_to secure-by-default with the option to turn off sanitization.

I think it works out for us because we don't use javascript: in our href attributes anyway since we consider it bad practice.

After fiddling with it a bunch, I got it to work.

  include ActionView::Helpers::UrlHelper
  alias rails_default_link_to link_to

  def link_to(*args, **kwargs)
    anchor_tag = rails_default_link_to(*args, **kwargs)
    return anchor_tag if kwargs[:keep_dirty]

    sanitize anchor_tag
  end

Then I spent like 2.5 hours trying to publish it as a gem, just to try out what it's like, and now I have my first gem! https://rubygems.org/gems/safe_anchor

I accept a lot of user input links and output them as anchor tags. As a result, I'm worried that there may be cases of users trying to inject Javascript into the href attribute.

I would like to override default link_to so that it sanitizes the output as a default, with an optional parameter to turn off sanitization

My understanding of your situation is that you have 2 different systems sharing the same JS and SCSS and therefore compiling into 1 big JS file and 1 big CSS file?

If that's the case and you're using Sprockets/AssetPipeline, you can split your CSS/JS into multiple folders with the main file named application.js or application.scss and Rails will compile them separately. Same can be done with Javascript.

Example:

# assets/stylesheets/backend/application.scss
# assets/stylesheets/frontend/application.scss

In your layout's stylesheet_link_tag, you just have to update the path accordingly.

I think you can restrict the access by creating another controller route, which dynamically return data depending on request.referer.

So for example, you'd have DownloadsController with a users_csv action. You can then do

if URI(request.referer).host == 'myappdomain.com'
  send_data ...
else
  render json: { errors: ['Permission Denied'] }, status: 403
end

When using Cockpit, I feel that it opens up a big vulnerability as the browser login allows unlimited attempts to login. Once the brute-force is successful, the attacker will be able to run commands with sudo privilege using this same password. Is there a good way to protect against this?

Using your example, I'm thinking more of only querying Page.first.content if the template itself uses page_content. I'm in a situation where my liquid templates are user generated, so I'm not sure what data will be required.

I'm working on an app that does serves http but also has some parts where ActionCable is used. How do I know how many threads does my app need? Is there a rough number?

How does websocket occupy the thread differently compared to http?

I'm following the installation guide of Vuetify and it requires me to add the following to webpack.config.js but since Rails has no such file, how should I go about adding these rules?

module.exports = {
  rules: [
    {
      test: /\.s(c|a)ss$/,
      use: [
        'vue-style-loader',
        'css-loader',
        {
          loader: 'sass-loader',
          // Requires sass-loader@^7.0.0
          options: {
            implementation: require('sass'),
            fiber: require('fibers'),
            indentedSyntax: true // optional
          },
          // Requires sass-loader@^8.0.0
          options: {
            implementation: require('sass'),
            sassOptions: {
              fiber: require('fibers'),
              indentedSyntax: true // optional
            },
          },
        },
      ],
    },
  ],
}

I'm new to using Liquid templates, but I'm wondering how do I load data dynamically in my controller? The reason is because all the data is stored in my db in different tables, and loading all of them requires a lot of join queries and more of than not, a single page will almost never use all of the queried data.

I don't think it's efficient to run 20+ queries to only use 5, is there a way to know what the Liquid needs and only load those when necessary?

https://authorization-server.com/oauth/authorize
?client_id=a17c21ed
&response_type=code
&state=5ca75bd30
&redirect_uri=https%3A%2F%2Fexample-app.com%2Fauth
&scope=photos

The above is a standard format for OAuth authorization URL, and how do I generate and store the state parameter? I understand that you can encode information inside for redirect purposes and it's also for CSRF prevention, but does this mean I need to have a column in my database to store the state? Do I need to invalidate it after 30 mins to keep it "unguessable"? It seems very overkill, and I am utterly confused as to what's a good way to do this.

I'm planning to integrate my app with Stripe payment gateway, but and looking from their dashboard and some docs, it seems like they already help you with issuing receipts and invoices. In that case, do I still have to issue and keep a record an invoice/receipt in my app by having an Invoice and a Receipt model??

I have a shopping cart item counter on my navbar that is first rendered by Rails then gets taken over by Vue once DOM contents are loaded. But the problem is that in between page load, Vue-Turbolinks has to destroy the Vue instance, wait for the page load, and then re-mount the Vue instance. This results in stale information showing on the browser (if the user has added more items to cart) while Vue is gone because v-text is down during this time.

Is there a way to work around this? I've tried v-cloak which works, but doesn't make for as good of a UX since the number temporarily disappears and reappears in between page load

<span v-text="rails.cart_items.length"><%= @shopping_cart.shopping_cart_items.length %></span>

Guys, I feel very stupid asking this but I still don't understand what is the purpose of data-behavior="vue" to initialize the Vue instance. How does this differ compared to doing <div id="app"><%= yield %></div> ? It feels like the serve exactly the same purpose.

Very cool to see how it works under the hood! Redis is quite a mystery for the most part since we generally only use it for very specific things, because that's how everyone does it. Things like caching/background jobs, etc. So it's good to see what really happens at Redis level

They're different programming languages. Both are high level, built on the programming language C.

Python has way more users than Ruby.
A lot of Python's usage are in the academia community.
Usage geared towards machine learning and data science.
Python can also be used for web development and has a popular framework - Django

Ruby is popularized by the Ruby on Rails web development framework.
Far more mature web development ecosystem compared to Python.
Most Ruby developers are working on Ruby on Rails.

These server-management episodes are so good! Whole new side of development that I find very difficult to learn on my own.

This is really cool! Is this provided by Hatchbox out of the box as well? (No pun intended)

I'd like to store users' API keys in my database. Lockbox was previously suggested to me, but I just came across attr_encrypted gem and they look like they achieve the same results to me.

I'd like to know usage aside, are they any different? I'm leaning towards attr_encrypted for ease-of-use, but would like to hear some professional opinion since I'm storing sensitive data.

Main question:
I've been looking into documenting my own code, and came across Yard and Rdoc. Right now, just trying it out, I have Yard installed. But are there other alternatives out there that I should consider and is there a reason I might want to pick Rdoc over Yard?

Side-Question 1:
I've never done documentation for my own code before since I basically stick to the RESTFUL and Rails conventions, so my code has been quite self explanatory. Where things get more complicated, I usually leave some comments (though I generally try to avoid this, because if it's complicated, usually it can be refactored). Is this a bad practice? Should I be documenting the codebase regularly moving forward?

Side-Question 2:
@Chris, any chance you will make a video series or just a single video on documenting Rails code?