blog.podqueue.fm

New PodQueue Premium feature: Pinboard integration

Sat, 13 Aug 2022 00:00:00 +0000

PodQueue Premium now supports automatically synchronizing all of your saved links to the third-party bookmarking service Pinboard!

Any existing links you have saved in PodQueue will be synchronized with their original save date when you first configure the integration, and any new links will automatically be saved to Pinboard as well, with an optional tag you can specify. Synchronization uses your Pinboard “add bookmarks as private by default” setting to determine if links saved to Pinboard are saved as public or private.

You can configure your Pinboard integration settings for PodQueue by going to “Pinboard Integration” in your PodQueue account settings.

No, You Don't Need a Cookie Popup on Your Site

Sat, 02 Apr 2022 00:00:00 +0000

TL;DR: No, you don’t need a cookie popup on your site. Yes, you do need to comply with the GDPR and the ePrivacy Directive.

A frequent question for people starting a website these days is: “Don’t I need a cookie popup?”

With cookie consent notifications seemingly everywhere, it’s a reasonable question. But just because other websites use cookie popups, doesn’t mean yours has to.

When I was building PodQueue, I wanted to be extremely sensitive to user privacy. I even wrote up a post about how to use Rails without setting session cookies. As it turns out though, as long as you’re willing to exclusively use certain kinds of first-party cookies, you do not need a cookie popup.

Don’t just take my word for it, though. Look at the regulations, the explanations, and the ongoing enforcement of cookie consent policies. GDPR.eu has a very good explainer article here, and the most important point for you if you want to avoid using a cookie popup is this:

Receive users’ consent before you use any cookies except strictly necessary cookies.

If you’re only using strictly necessary cookies, you don’t need a cookie popup. So, what are “strictly necessary cookies”?

Strictly necessary cookies — These cookies are essential for you to browse the website and use its features, such as accessing secure areas of the site. Cookies that allow web shops to hold your items in your cart while you are shopping online are an example of strictly necessary cookies. These cookies will generally be first-party session cookies.

The linked article then goes on to contrast these with other types of cookies (preferences, statistics, and marketing), but the important takeaway is as long as you only use first-party session cookies, you don’t need a cookie popup.

Yes, this means you need to read up on the other kinds of cookies and ensure you’re not using them. Yes, this may have technical implications for how you design your website. But the payoffs—respecting your users’ privacy and avoiding annoying popups—are well worth the investment.

Disclaimer: I am not a lawyer, and nothing in this post should be taken as legal advice.

Flexible Passwordless Rails Authentication with `devise-passwordless`

Sun, 13 Mar 2022 00:00:00 +0000

For PodQueue, I wanted users to be able to sign up with just an email address, instead of having to also pick a username and password at sign-up time. You’ve probably seen this strategy with some other online services like Slack, where the login process can be handled by a so-called “magic link” that gets emailed to the email address associated with your account, and clicking the link logs you in. The problem is, I already had users with passwords, and I still wanted to support password-based authentication for users who want it—the passwordless login flow is just available for users who find that easier.

You may be concerned that passwordless email-based login is “insecure”, but if you allow for email-based account/password recovery (e.g. the Devise :recoverable strategy), you already have an email-based login process even if you don’t call it that.

I was already using Devise for authentication, and settled on the devise-passwordless gem to provide the core of my passwordless authentication strategy. Out of the box, devise-passwordless assumes you’re only going to use a passwordless authentication strategy, but with a little work you can adapt it to work flexibly alongside password-based authentication. This assumes you’ve already set up Devise, and followed the default install intructions for devise-passwordless for your Devise resources. The only resource I’m using Devise for is my User model, which I assume will be the case for most other projects as well, but obviously you’ll need to adapt things for your particular goals and Devise configuration.

I also assume you have templates generated for overriding your Devise controllers, with e.g.:

rails generate devise:controllers devise/users

You should now have overridable Devise controllers in app/controllers/devise/users/ and app/controllers/devise/devise-passwordless/. Your config/routes.rb should have a Devise configuration like the following:

devise_for :users, controllers: { registrations: 'devise/users/registrations',
                                  sessions: 'devise/passwordless/sessions' }
devise_scope :user do
  get '/users/magic_link',
      to: 'devise/passwordless/magic_links#show',
      as: 'users_magic_link'
end

You then need to override the default devise-passwordless sessions controller at app/controllers/devise/devise-passwordless/sessions_controller.rb so that it will use the default password-based authentication method if a password parameter is present. Mine looks like the following:

# frozen_string_literal: true

module Devise
  module Passwordless
    class SessionsController < Devise::SessionsController
      def create
        super and return if create_params[:password].present?

        self.resource = resource_class.find_by(email: create_params[:email])
        self.resource ||= resource_class.find_by(username: create_params[:email])
        if self.resource
          resource.send_magic_link(create_params[:remember_me])
          set_flash_message(:notice, :magic_link_sent, now: true)
        else
          set_flash_message(:alert, :not_found_in_database, now: true)
        end

        self.resource = resource_class.new(create_params)
        render :new
      end

      protected

      def translation_scope
        if action_name == 'create'
          'devise.passwordless'
        else
          super
        end
      end

      private

      def create_params
        resource_params.permit(:email, :password, :remember_me)
      end
    end
  end
end

The main things I’ve modified here are permitting the :password param in create_params, and calling out to super if it’s present. I also allow logging in by username or email address, so there’s some extra code to do that as well.

You’ll also need to allow users to modify their account without a password. I have this in app/controllers/devise/users/registrations_controller.rb to allow this for all users:

protected

# Allow updating Devise resources without the current password
def update_resource(resource, params)
  if params[:password].blank?
    params.delete(:password)
    params.delete(:password_confirmation) if params[:password_confirmation].blank?
  end
  resource.update(params)
end

Since we’re using devise-passwordless for our sessions controller, we also need to add a few extra keys to config/locales/devise.en.yml, e.g.:

en:
  devise:
    passwordless:
      user:
        signed_in: "Signed in successfully."
        signed_out: "Signed out successfully."
        already_signed_out: "Signed out successfully."

You may also want to customize some user flows, account settings, or email views depending on if a user has a password set or not. You can easily check this with e.g. current_user.encrypted_password.blank?.

Using a Rails App Layout with Jekyll

Sat, 12 Mar 2022 00:00:00 +0000

There’s a number of different strategies you can use to host a blog for your app or company, and for PodQueue I went with the tried-and-true “static Jekyll site on a blog subdomain” approach. There are tradeoffs to every approach, and one here is that I initially ran the blog with a generic Jekyll theme just to have something up and running. I wanted the blog to instead have the same styling and layout as the main site with just a few blog-specific tweaks, so here’s how I accomplished that.

The main PodQueue website runs on Rails, and has an app-wide layout used for most pages. So to generate my Jekyll layout, I have a single page/endpoint in the Rails app that uses that layout with Jekyll’s {{ content }} templating tag as the only content. I can then just download that /layout endpoint as the HTML I’m going to use for my Jekyll layout (_layouts/default.html).

As I mentioned, there are a few blog-specific tweaks I want to add to the Rails-generated layout before using it as my Jekyll layout (e.g. YAML front matter, changing “PodQueue” to “PodQueue Blog”, using Jekyll’s {{ page.title }}, etc.). I made these changes once, then generated a patch file with:

diff -u layout default.html > layout.patch

Now, when I want to update the Jekyll layout from the Rails layout, I can simply re-download the layout, apply the patch, and overwrite my default.html.

Just for good measure, I’ve wrapped all these steps into a script that will automatically update my Jekyll layout from my Rails layout (as well as refresh the patch so that drift over time doesn’t result in patch rejection). Eventually, I can automate this to trigger whenever a successful deploy happens, or just on a periodic basis. You may especially want to do this if you’re referring to production assets (JS/CSS/etc.) which will change with each deploy and become unavailable (I’m using a CDN configuration that allows old assets to stick around, so it’s not quite as crucial). You’ll also want to check that any relative URLs in your layout are correct, and change them to absolute URLs if necessary in your initial patch configuration.

Announcing PodQueue Gift Certificates

Sat, 04 Dec 2021 00:00:00 +0000

Just in time for the holidays, we’ve added support for Gift Certificates to PodQueue! You can find out more about our gift certificates here: https://podqueue.fm/pages/gift_certificates

For the initial version, we’re only selling $50 gift certificates (equivalent to a one year subscription at the annual rate). Certificates can also be applied to an existing PodQueue account and used for any future invoices!

PodQueue Referral Program - Give a Month, Get $5

Sat, 09 Oct 2021 00:00:00 +0000

PodQueue Now Has Search Support!

Sun, 26 Sep 2021 00:00:00 +0000

People are saving enough links in PodQueue that they might need some help finding something they’ve saved or listened to earlier, so we’ve added a “Search” feature that will search through episodes and links you’ve saved in your PodQueue account!

Giving Back to Rails with rails-hidden_autocomplete

Sun, 19 Sep 2021 00:00:00 +0000

In the course of developing PodQueue, we stumbled across a longstanding bug in Firefox that will populate hidden form inputs with random values if they don’t have the attribute autocomplete="off".

Since PodQueue is built on Rails, and Rails uses hidden form inputs extensively for things like CSRF protection, we wound up needing to modify Rails methods that emit hidden form inputs to add this attribute, so that Firefox users wouldn’t see unexpected behavior.

To give back to the Rails community, we’ve now packaged this into a standalone Ruby gem that any Rails 6.1 application can easily use: rails-hidden_autocomplete

When installed in a Rails app, this gem modifies all the built-in locations that Rails emits a hidden form input to add the necessary autocomplete="off" attribute, preventing Firefox from accidentally overwriting the hidden input values.

Generating Static Error Pages with Rails

Sun, 19 Sep 2021 00:00:00 +0000

For PodQueue, I wanted to generate static error pages that used the same Rails layout and branding as the main site, and while there are many approaches floating around for this, none quite worked exactly the way I wanted them to (or at all) with Rails 6 and Heroku.

The most promising approach I found was this one by Ryan Schultz, however, it was written in 2013 and I had issues with getting the ActionDispatch::Integration::Session-based page rendering it uses to work. It still forms the basis for my solution though, which is to add a new rake app:static task to generate the static pages.

So in my Rails app’s lib/tasks/app.rake I have:

You’ll notice that a major difference here is that I’m using ApplicationController::Renderer to render the pages into static files, since this seems to be the preferred way of doing it now (specifying the hostname and HTTPS, just in case). There’s also some extra work I’m doing at the end for the Heroku-specific error pages application-error.html & maintenance-mode.html, which get pushed to an S3 bucket. Since the Heroku error pages also get served via an <iframe>, I use Nokogiri to rewrite relative asset paths into absolute URLs. (If you’re not using Heroku, you can ignore all that.)

The “regular” error pages just get written out to the public directory and served normally. The app:static task is hooked onto asset precompilation so that it happens afterwards every time I run a deploy - this is done by using enhance in my main Rakefile like so:

Rake::Task['assets:precompile'].enhance do
  Rake::Task['app:static'].invoke
end

You may have also noticed that I said I wanted to use the main application layout for my errors, but I’m using layout/errors in the task. This is because I also do need some error-page-specific logic while still inheriting from the main layout (in app/views/layouts/errors.html.erb):

Setting content_for :error_page lets us tell from any other layout or view if we’re inside the static error page rendering context, and the :stylesheets content is used in the main layout to have error-page specific CSS.

One important thing for the way I use this is that I also use Devise for authentication and ApplicationController.renderer doesn’t have access to Devise’s Warden::Proxy instance by default, so if you try to use any Devise methods like user_signed_in? or current_user, you’ll get the exception:

Devise could not find the `Warden::Proxy` instance on your request environment

So for any layout/view path triggered by our static error pages, we need to guard any Devise calls with a check on content_for?(:error_page), e.g. <% if (!content_for?(:error_page)) && user_signed_in? %>.

I’m also using the high_voltage gem to handle my error pages, but as long as you have a route for your error pages you should still be able to use this technique. Since the error pages use compiled asset slugs that will change constantly, I don’t keep the generated pages in version control.

Thanks for reading, and I hope this approach helps you navigate the confusing landscape of Rails static error pages!

Removing "?ref=producthunt" from your search results

Fri, 17 Sep 2021 00:00:00 +0000

After launching PodQueue, I submitted it to many of the usual product launch sites, including Product Hunt. In submitting PodQueue, I set the webpage to be “https://podqueue.fm”, which Product Hunt turns into the outbound tracking link “https://www.producthunt.com/r/f179c9b85faf16”, which in turn resolves to “https://podqueue.fm/?ref=producthunt”. Fair enough, I could do some click/conversion tracking from that if I wanted to, although I didn’t ask for it and there’s no way to turn it off.

Unfortunately, though, what started happening after this is that for various search engines, I now had two search results for the same page competing with each other, “https://podqueue.fm” (which I wanted people to see and click on) and “https://podqueue.fm/?ref=producthunt” (it’s the same page but with a not-even-correct referrer now!).

I took a double-barrel approach to solving this, and while you may be able to fix it with just one or the other, I fixed it with both, and no longer see duplicated entries for my landing page in search results.

The first was to use an HTTP 301 Moved Permanently redirect whenever a ref parameter is passed. Since PodQueue runs on Rails, I could do this with a line in the relevant controller action:

redirect_to root_url, status: :moved_permanently and return if params['ref'].present?

Now, requesting “https://podqueue.fm/?ref=producthunt” will tell clients that they should permanently redirect to “https://podqueue.fm” instead.

The second technique was to introduce a metadata tag inside the <head> of the HTML returned at the root URL:

<link rel="canonical" href="https://podqueue.fm">

This tells clients that parse the HTML that the canonical representation of this link is “https://podqueue.fm”.

Note that you shouldn’t hardcode this in your layout, since then every page will say that the canonical URL is the root URL - you should set it dynamically or conditionally depending on what you want to accomplish.

With both of these techniques deployed and in production, search engines now show just my preferred URL for my site instead of two duplicate entries!