DEV Community: Thiago David

[Boost]

Thiago David — Fri, 21 Feb 2025 14:45:02 +0000

Hospedando seu site estático no Amazon S3 🚀

Carlos Henrique ・ Feb 21

Exposing Plex Application with Cloudflare Tunnel and Authenticate with Zero Trust

Thiago David — Mon, 10 Feb 2025 18:21:27 +0000

For tech enthusiasts who value practicality and organization when watching movies and series, this article is for you. Today, we'll discuss the Plex application, how to expose it to the internet (outside your local network), and how to protect it from unauthorized access using Cloudflare services.

Requirements

To ensure everything runs smoothly, the following prerequisites are essential:

A Cloudflare account.
A custom domain (e.g., mydomain.com).
Optional: A Google Cloud Console account (for Google login integration).

⚠️ Note: Cloudflare will need to control your domain's DNS. If you're currently using another provider (e.g., GoDaddy, Vercel, Netlify, etc.), you'll need to switch to Cloudflare for the services we'll use here.

What is Plex?

Plex is a media server application that allows you to organize, stream, and access your personal media library (movies, TV shows, music, photos, and videos) from anywhere. It functions as a media server installed on your computer or another compatible device, and a player that can be used on various devices such as smartphones, smart TVs, tablets, consoles, and browsers.

In essence, Plex consolidates all media from a specific device (typically a server) and serves it to other devices on the same network that have the Plex app installed.

What is Cloudflare?

Cloudflare is a company that offers a global network of services to improve the security, performance, and availability of websites, applications, and APIs. It acts as a CDN (Content Delivery Network) and a reverse proxy, protecting servers against attacks (e.g., DDoS) and speeding up page loading by caching content across multiple global locations.

Additionally, Cloudflare provides services such as fast and secure DNS, firewalls, load balancing, API security, corporate VPNs, and Zero Trust solutions.

Cloudflare Tunnel

The Cloudflare Tunnel is a service that allows you to securely expose internal applications or servers to the internet without opening firewall ports or using a public IP. It creates an encrypted tunnel between your local network and Cloudflare's infrastructure.

Zero Trust

Cloudflare Zero Trust is a security platform that implements the Zero Trust model, ensuring that no user, device, or network is automatically trusted. It protects access to internal applications, networks, and devices without relying on traditional VPNs.

With Cloudflare Zero Trust, businesses can control who accesses their systems, from where, and under what conditions, ensuring maximum security.

Getting Started

Let's begin by installing Plex on the computer that will serve as your media server.

Step 1: Create a Plex Account

Visit https://watch.plex.tv/pt/live-tv and complete the sign-up process.

Step 2: Download the Media Server

Once you have access to your account, go to https://www.plex.tv/pt-br/media-server-downloads/ and download the Plex Media Server. After downloading, follow the installation steps as you would for any other Windows program.

At this point, you'll have a Plex server running on your machine. After installation, Plex will likely redirect you to its dashboard. Here, you'll notice several options, such as Movies & Shows and Live TV. Personally, I tend to hide these since I don't use them.

Plex Configuration

Before moving on to Cloudflare, there are a few things you should be aware of to ensure your media appears in Plex.

Adding Media Libraries

To add your media directories, go to Settings -> Media Libraries -> Add Library. Here, you can define the type of library (movies, TV shows, etc.) and select the desired folder path. Save your changes.

If you don't see any movies or TV shows in Plex, there are two things you can check:

1. Enable Automatic Media Scanning

Go to Settings -> Libraries. You'll see two options: Scan my library automatically and Scan my library periodically. Enable both to ensure new media is detected and added to Plex.

2. Folder Structure

Plex expects a specific folder structure to properly index and fetch metadata for your media.

You can refer to Plex's official articles on organizing movies and TV shows. Below is a basic example:

Movies:

Pattern: /Movies/MovieName (release year)/MovieName (release year).extension
Example:

/Movies
    /Avatar (2009)
      Avatar (2009).mkv
    /Batman Begins (2005)
      Batman Begins (2005).mp4
      Batman Begins (2005).en.srt
      poster.jpg

Tv Shows:

Pattern: /Series/SerieName (release year)/Season (season number)/S01E01 - Name.extension
Example:

/TV Shows
   /Doctor Who (1963)
      /Season 01
         Doctor Who (1963) - s01e01 - An Unearthly Child (1).mp4
         Doctor Who (1963) - s01e02 - The Cave of Skulls (2).mp4
   /From the Earth to the Moon (1998)
      /Season 01
         From the Earth to the Moon (1998) - s01e01.mp4
         From the Earth to the Moon (1998) - s01e02.mp4
   /Grey's Anatomy (2005)
      /Season 00
         Grey's Anatomy (2005) - s00e01 - Straight to the Heart.mkv
      /Season 01
         Grey's Anatomy (2005) - s01e01 - pt1.avi
         Grey's Anatomy (2005) - s01e01 - pt2.avi
         Grey's Anatomy (2005) - s01e02 - The First Cut is the Deepest.avi
         Grey's Anatomy (2005) - s01e03.mp4
      /Season 02
         Grey's Anatomy (2005) - s02e01-e03.avi
         Grey's Anatomy (2005) - s02e04.m4v
   /The Colbert Report (2005)
      /Season 08
         The Colbert Report (2005) - 2011-11-15 - Elijah Wood.avi
   /The Office (UK) (2001) {tmdb-2996}
      /Season 01
         The Office (UK) - s01e01 - Downsize.mp4
   / The Office (US) (2005) {tvdb-73244}
      /Season 01
         The Office (US) - s01e01 - Pilot.mkv

Cloudflare Setup

Now that your Plex server is running and your media is accessible on your local network, let's move on to exposing it to the internet using Cloudflare.

Step 1: Create a Cloudflare Account

Visit https://dash.cloudflare.com/login and complete the sign-up process. Once done, you'll be redirected to the Cloudflare dashboard. On the home screen, you'll be prompted to add and configure your domain's DNS settings with Cloudflare.

Follow the steps provided by Cloudflare to adjust your DNS settings.

Step 2: Zero Trust Dashboard

After configuring your domain, navigate to the Zero Trust Dashboard (accessible via the sidebar or directly at https://one.dash.cloudflare.com/). On your first visit, you'll be asked to create a "team name." Remember this name, as we'll use it later for Google integration.

Select the plan that suits your needs. For this guide, we'll use the free plan, which is sufficient for our purposes. Cloudflare will ask for a credit card, similar to other providers like AWS or DigitalOcean.

Step 3: Create a Tunnel

To configure the tunnel, follow these steps:

In the sidebar, expand the Networks menu and click on Tunnels.
Click Create Tunnel, give it a name, and follow the installation and activation steps for the cloudflared adapter.
In Public Hostnames, specify a subdomain (e.g., plex.mydomain.com) and select your domain.
Under Service, choose the http protocol and point it to your local Plex server at localhost:32400.

If everything is set up correctly, the tunnel status will show as Healthy.

At this point, you can access your Plex server via the URL you specified. However, this leaves your server open to anyone, which is not ideal for privacy or performance. Let's secure it further.

Access Control with Zero Trust

To ensure only authorized users can access your Plex server, we'll use Cloudflare's Access feature.

Google Authentication (Optional)

If you want to integrate Google login, follow these steps:

Visit the Google Cloud Platform console. Create a new project, name the project, and select Create.
On the project home page, go to APIs & Services on the sidebar and select Dashboard.
On the sidebar, go to Credentials and select Configure Consent Screen at the top of the page.
Choose External as the User Type. Since this application is not being created in a Google Workspace account, any user with a Gmail address can login.
Name the application, add a support email, and input contact fields. Google Cloud Platform requires an email in your account. Note: In the Scopes section, we recommend adding the userinfo.email scope. This is not required for the integration, but shows authenticating users what information is being gathered. You do not need to add test users.
Return to the APIs & Services page, select Create Credentials > OAuth client ID, and name the application.
Under Authorized JavaScript origins, in the URIs field, enter your team domain:
```
https://<your-team-name>.cloudflareaccess.com
```
You can find your team name in Zero Trust under Settings > Custom Pages.
Under Authorized redirect URIs, in the URIs field, enter the following URL:
```
https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback
```
Google will present the OAuth Client ID and Secret values. The secret field functions like a password and should not be shared. Copy both values.

Next, go to the Zero Trust dashboard, navigate to Settings -> Authentication, and add a new login method using the Google credentials you just created.

User Lists

Before creating access policies, let's create a list of pre-approved users:

Go to My Team -> Lists and click Create Manual List.
Name the list (e.g., Plex Users), set the type to User Emails, and add the emails of authorized users.

Access Policies

We are in the final stage, and now we will create our policies, which are essentially the rules that users attempting to access the application must follow. In this step, we will create two policies. One to ensure that users listed in our previously created list have unrestricted access.

Creating the First Policy

Go to access -> policies in the Zero Trust dashboard and click on Create policy.
In this first policy, we will specify that any user who logs in with the email specified in the list created earlier will have free access. Choose a name that aligns with the policy (e.g., pre-approved users).
In Action, select Allow, and the session duration is up to you.
Under Rules, keep only one instruction of Include. In the selector, choose Email List (if you haven’t created the list, you can simply select Emails), and in the value field, choose your list.

You can save and create a new policy.

Creating the Second Policy

For this new policy, specify a name related to requesting access.
In Action, define Allow.
Under Rules, add the selector Login Methods, and in the value, specify Google and One-time Pin. These methods may vary depending on your needs. If you haven't integrated with Google, you can select only the Pin.
To ensure users not on our pre-approved lists can request access, check the Purpose justification checkbox. Optionally, provide a message for users to explain why they need access. Then, check the Temporary authentication checkbox and provide your email or the email of the person responsible for approving new user access. It is important to note that new users who go through this requested access stage cannot have indefinite access (usually, it allows access for up to 1 day). Therefore, I recommend that if you want to grant permanent access, add their email to the list we created earlier.

After saving the policy, we can proceed to the final stage.

Final Steps: Creating the Application

To apply these policies to your Plex server:

Go to Access -> Applications.
Click Add an Application and select Self-Hosted.
Name your application and specify the same URL used in your tunnel.
Under Access Policies, select the two policies you created, ensuring the pre-approved policy is evaluated first.

Conclusion

Congratulations! Your Plex server is now securely exposed to the internet, with controlled access to ensure only authorized users can stream your media. This setup combines the convenience of Plex with the robust security of Cloudflare, giving you peace of mind and a seamless streaming experience. Enjoy your media library from anywhere!

Protecting sveltekit routes from unauthenticated users

Thiago David — Mon, 27 Nov 2023 21:17:59 +0000

While developing a SvelteKit app, I found myself contemplating the intricacies of authentication, specifically regarding the proper storage of user session data and securing access to private routes. In my case, I was working with a Rails API handling user registration and authentication through Devise JWT. I opted not to use any ORMs (such as Prisma or Sequelize).

As I delved into the available resources, I came across articles detailing route protection using cookies and hooks. However, adapting their code to meet my specific needs proved challenging. My requirements included integrating a Rails API for user management, avoiding the use of ORMs, and ensuring secure handling of sensitive data.

In this article, I'll guide you through handling user session data and implementing routing protection in such a scenario.

Understanding HTTP Cookies

HTTP Cookies are familiar components for anyone who has traversed websites. Essentially, cookies are small files stored in browsers, typically containing information like authentication tokens or session data. To enhance security, we prefer not to store sensitive data directly in cookies. This concern led to the introduction of HTTPOnly Cookies, which ensures that the server receives the cookie with each specific request, while JavaScript remains unable to access it.

Unpacking SvelteKit Hooks

SvelteKit Hooks, according to the documentation, are app-wide functions that you declare, and SvelteKit calls them in response to specific events. This grants you fine-grained control over the framework's behavior. Leveraging hooks allows us to exercise control over each request passing through our application, enabling us to capture the pathname of the URL the user is attempting to access. This capability proves crucial for redirecting unauthenticated users.

Implementation Steps

Before diving into the implementation details, I assume you already have an external API application, like a Rails or Node.js server, up and running. This allows us to focus more on the SvelteKit implementation. Let's proceed by creating a new SvelteKit app using npm.



npm create svelte@latest sveltekit-auth
cd sveltekit-auth
npm install

Now that we have the initial structure in place, let's create some basic forms for testing authentication. We'll create three new routes: signin, signup, and logout.

on the signin and signup i will create two files.

+page.svelte
+page.server.js

and on the logout i will only create one file, the +page.server.js.

the structure it will be like that:

Before delving into the code for these files, let's create a SvelteKit store to maintain user data in runtime memory. Inside the src/lib folder, create a store folder, and within it, a file named user.js.

Inside user.js, add the following code:



// src/stores/user.js
import { writable } from "svelte/store";

export const user = writable({
  email: "",
  name: "",
})

This store provides a global object to access and manipulate user data.

Next, let's create basic forms for signup and signin. These forms are simple for testing purposes and lack styling for simplicity.



<!-- signup/+page.svelte -->
<h1>This is the Signup page</h1>
<form action="/signup" method="POST">
  <input type="text" name="name" placeholder="Name">
  <input type="text" name="email" placeholder="email" />
  <input type="password" name="password" placeholder="Password" />
  <button type="submit">Sign up</button>
</form>

signin page:



<!-- signin/+page.svelte -->
<h1>This is the signin page</h1>
<form action="/signin" method="POST">
  <input type="text" name="email" placeholder="email" />
  <input type="password" name="password" placeholder="Password" />
  <button type="submit">Sign in</button>
</form>

Notice that we retained the initial +page.svelte in the root route (http://localhost:5173/). Why? We'll treat it as a "private" page that doesn't accept access from unauthenticated users. In this file, we'll set up the following code:



<!-- routes/+page.svelte -->
<h1>This will be our protected page</h1>
<form action="/logout" method="post">
  <button>Logout</button>
</form>

Now, let's set up the server files for each route. For the signup route, create +page.server.js:



// signup/+page.server.js
import { user } from '$lib/stores/user.js'
import { redirect } from '@sveltejs/kit'

//create a new action called default passing the cookies, request and fetch as parameters
export const actions = {
  default: async ({ cookies, request, fetch}) => {
    //retrieve the form data from the request and set it to the variables
    const data = await request.formData()
    const email = data.get('email')
    const password = data.get('password')
    const name = data.get('name')

    //check if the variables are valid and if not, return an error
    if (
            typeof email !== 'string' ||
            typeof password !== 'string' ||
            !email ||
            !password
        ) {
            return {
        status: 400,
        body: {
          success: false,
        }
      }
        }

    //send the data to the backend API (use your endpoint in this case)
    const response = await fetch('http://localhost:3000/users', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        user: {
          email,
          password,
          name
        }
      })
    })

    //if the response is ok, set the cookies and redirect to the homepage
    if (response.ok) {
      const data  = await response.json()
      //setting the cookies of user and jwt
      cookies.set('user', JSON.stringify(data.user))
      cookies.set('jwt', response.headers.get('Authorization'))
      let obj = {
        ...data,
        jwt: response.headers.get('Authorization')
      }
      user.set(obj)

      //redirect user to the protected page
      throw redirect(302, '/')
    } else {
      //if the response is not ok, return the errors
      const { errors } = await response.json()
      return {
        status: 400,
        body: {
          success: false,
          errors
        }
      }
    }
  }
}

For the signin route, create +page.server.js:



// signin/+page.server.js
import { user } from '$lib/stores/user.js'
import { redirect } from '@sveltejs/kit'

export const actions = {
  default: async ({ cookies, request, fetch}) => {
    const data = await request.formData()
    const email = data.get('email')
    const password = data.get('password')

    if (
            typeof email !== 'string' ||
            typeof password !== 'string' ||
            !email ||
            !password
        ) {
            return {
        status: 400,
        body: {
          success: false,
        }
      }
        }

    const response = await fetch('http://localhost:3000/users/sign_in', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        user: {
          email,
          password
        }
      })
    })

    if (response.ok) {
      const data  = await response.json()
      cookies.set('user', JSON.stringify(data.user))
      cookies.set('jwt', response.headers.get('Authorization'))
      let obj = {
        ...data,
        jwt: response.headers.get('Authorization')
      }
      user.set(obj)

      throw redirect(302, '/')
    } else {
      const { errors } = await response.json()
      return {
        status: 400,
        body: {
          success: false,
          errors
        }
      }
    }
  }
}

Finally, for the logout route, create +page.server.js:



// logout/+page.server.js
import { redirect } from '@sveltejs/kit'

export const actions = {
  default: async ({ cookies}) => {
    //set the cookies to null and redirect
    cookies.set('user', null)
    throw redirect(302, '/')
  }

}

Now, let's implement the hook. Create a new file, hooks.server.js, in the src folder.



// src/+hooks.server.js
import { redirect } from "@sveltejs/kit";

// define the routes of we want to be possible to access without auth
const public_paths = [
  '/signup',
  '/signin'
];

// function to verify if the request path is inside the public_paths array
function isPathAllowed(path) {
  return public_paths.some(allowedPath =>
    path === allowedPath || path.startsWith(allowedPath + '/')
  );
}

export const handle = async ({ event, resolve}) => {
  let user = null
  // check if the cookie exist, and if exists, parse it to the user variable
  if(event.cookies.get('user') != undefined && event.cookies.get('user') != null){
    user = JSON.parse(event.cookies.get('user'))
  }
  const url = new URL(event.request.url);

  // validate the user existence and if the path is acceesible
  if (!user && !isPathAllowed(url.pathname)) {
    throw redirect(302, '/signin');
  }

  if(user){
    //set the user to the locals (i explain this later on the article)
    event.locals.user = user

    // redirect user if he is already logged if he try to access signin or signup
    if(url.pathname == '/signup' || url.pathname == '/signin'){
      throw redirect(302, '/')
    }
  }

  const response = await resolve(event)

  return response
}

This hook captures every request passing through the application. Using the handle function, we access the cookies set previously, determine whether the user should be redirected, and set the user store again. Note the use of event.locals to pass user data through server-side functions with the request.

On the routes folder, create the follow files

+layout.svelte
+layout.server.js

on the +layout.svelte set the code:



<!-- routes/+layout.svelte -->
<script>
  import { user } from '$lib/stores/user.js'
  export let data
  $user = data.user
</script>
<!-- i will put that for it can be possible to see the user data consistance -->
<h1>User info :</h1>
<pre>{JSON.stringify($user, null, 2)}</pre>
<slot />

and the last one, the +layout.server.js:



// routes/+layout.server.js
export const load = async ({ locals }) => {
    return {
        user: locals.user,
    }
}

Now, you can test the implementation. Attempting to access the protected route (/) without signing in will redirect you to the signin page.

Conclusion

In this article, I aimed to simplify the understanding of authentication flow and the use of hooks in SvelteKit. Having encountered some difficulties myself in grasping these features, I hope this guide proves helpful for your understanding as well.