32 Matching Annotations
  1. Aug 2022
  2. May 2022
    1. You should mentioned what you listed after the word try_files. Here's what I ended up using that seemed to work: try_files $uri $uri/index.html $uri.html /index.html; The /index.html at the end needs to match the fallback: 'index.html' part of your adapter-static config. Otherwise going directly to a route that doesn't have a matching file at that path -- such as any route with a dynamic param like [id] -- will result in a 404.
  3. Jan 2022
    1. export const load: Load = async ({ page, session }) => { if (!isPublic(page.path) && !isAuthenticated(session)) { console.log('Unauthorized access to private page'); return { redirect: '/', status: 302 }; } else { console.log('Auth OK'); } return {}; };
    2. In hooks.js I have a handle function that basically does request.locals.jwt = cookies.jwt, and then a getSession function that returns { jwt: locals.jwt }
    1. It has many advantages but the main reason for me is that it simplifies your front end code. It's not perfect by any means, but overall its cons are worth it IMO.
    1. import { goto } from '$app/navigation'; function routeToPage(route: string, replaceState: boolean) { goto(`/${route}`, { replaceState }) } replaceState == true will replace the route instead of adding to the browser history. So, when you click back, you will not go back to the route you came from.
  4. Oct 2021
    1. while with server/externalFetch there is no direct way to pass cookie headers from the original request to the external one
    2. Right now I am working around this issue by having an internal [...api].js, then call fetch for that endpoint (which automatically passes on cookies) and from there hit the actual external endpoint. It works, there is no risk of leaking anything, but imo shouldn't be necessary.
    3. Sure you can abuse session but I don't like that since there is the risk of exposing credentials to client side code.
    4. I am currently circumventing this issue by using getSession to have access to the cookies/headers in the load method

      We did something similar for a while...

    1. This function allows you to modify (or replace) a fetch request for an external resource that happens inside a load function that runs on the server (or during pre-rendering). For example, your load function might make a request to a public URL like https://api.yourapp.com when the user performs a client-side navigation to the respective page, but during SSR it might make sense to hit the API directly (bypassing whatever proxies and load balancers sit between it and the public internet).
  5. Jun 2021
    1. export function get(req, res) { if (req.headers.authorization) { res.writeHead(200); res.end(JSON.stringify({ message: req.headers.authorization })); } else { res.writeHead(200); res.end(JSON.stringify({ message: 'unauthorized' })); } }
  6. May 2021
    1. if (parsed.protocol) { // external fetch response = await fetch(parsed.href, /** @type {import('node-fetch').RequestInit} */ (opts)); } else { // otherwise we're dealing with an internal fetch const resolved = resolve(request.path, parsed.pathname);
    1. This function runs on every request, for both pages and endpoints, and determines the response. It receives the request object and a function called resolve, which invokes SvelteKit's router and generates a response accordingly.
    2. This allows you to modify response headers or bodies, or bypass SvelteKit entirely
    1. CSR asking my Python backed directly (over nginx). Basically, in my particular situation, I want to use most shorter paths for SSR or CSR cases when I have a separate API server under the same domain and nginx frontend.
    2. on CSR it connects to the svelte-kit endpoint which just use a localhost connection. and to optimize this you can use unix sockets in your endpoints to connect to backend server
    3. ah you are talking about a external api endpoint server? then you could use the svelte-kit endpoints as proxy handler
    1. This looks cool but right now, let's say i have an external api which depends on users cookies, the cookies only gets send through internal sk endpoints while ssr even if its the same domain. Couldn't we pass the 'server' request to the serverFetch hook? I would currently have to patch package svelte kit to pass request headers to the external api or create an sk endpoint which proxies the request.