Auth shouldn't be a paid service!

The goal of Lucia v3 was to be the easiest and cleanest way to implement database-backed sessions in your projects. It didn't have to be a library. I just assumed that a library will be the answer. But I ultimately came to conclusion that my assumption was wrong. I don't see this change as me abandoning the project. In fact, I think it's a step forward. If implementing sessions wasn't easy, I wouldn't be deprecating the package. But why wouldn't a library be the answer? It seems like a such an obvious answer. One word - database. I talked about how database adapters were a significant complexity tax to the library. I think a lot of people interpreted that as maintenance burden on myself. That's not wrong, but the bigger issue is how the adapters limit the API. Adapters always felt like a black box to me as both an end user and a maintainer. It's very hard to design something clean around it and makes everything clunky and fragile, especially when you need to deal with TypeScript shenanigans.

the only part I agree with is that it could be annoying to change behaviour based on this variable, but any library worth its salt will use this to set sensible defaults and allow explicit overrides for all of the settings.

The biggest mistake I see is thinking of a Job to be Done as an activity or task. Examples include store and retrieve music or listen to music. These are not Jobs; rather, they are tasks and activities — which means they describe how you use a product or what you do with it.

Jobs to be done theory, also called jobs theory, posits that people don’t buy products; they “hire” them to do jobs, such as solving a problem or fulfilling a desire.

The Markdown syntax is not supported, but you can add bold styling with single asterisks, which is the standard Markdown syntax for italic. Very confusing!

I’m not a believer in languages designed by a committee and I have faith in Matz making reasonable decisions at the end of the day.

By the way, while .: doesn’t really get any awards for code elegance, it least it’s aligned with another existing pattern in Ruby. Victor Shepelev echoes my sentiment almost precisely here.

However, I also feel that Ruby sometimes seems too focused on being backwards compatible, to a point where it risk hurting the ecosystem. I think this thread is a good example, because it seems like such a small and benign change, yet it's taken several years and lots of back and forth, and in the end the proposed change wasn't even applied(!?).

Don't use the timestamp type to store timestamps, use timestamptz (also known as timestamp with time zone) instead.

temporal_tables extension if you are in a pinch and want to use that for row versioning in place of a lacking SQL 2011 support.

Don't use the type varchar(n) by default. Consider varchar (without the length limit) or text instead.

varchar(n) is a variable width text field that will throw an error if you try and insert a string longer than n characters (not bytes) into it.

Better expressivity. RDF* allows every LPG to be efficiently converted into an RDF model. On the other hand, LPGs cannot fully represent RDF* because of the rich expressivity of the latter.

The rich internal structure of LPGs results in more efficient storage and faster data traversals and queries.

however, due to the arbitrary data structure design, LPGs are not as practical for modelling ontologies and other structured data representations as RDF models.

LPG edges/connections can have types and attributes (properties as the name suggests) natively, making the LPG data structure more dense, compact, and informative compared to RDF.

There are two camps of Graph database, one side is RDF, where they are strict with their format, and somewhat limited for their extensibility. The other side is LPG, where they can define labels to the relationships.

Building a knowledge graph with a property graph database is straightforward compared to the alternatives. Unlike RDF, property graphs were designed as a database model (rather than data exchange format) for applications and analytics.

In a native property graph like Neo4j, the physical storage model is isomorphic to the logical model. What you draw is what you store.

SQL/PGQ reduces the difference in functionality between relational DBMSs and native graph DBMSs. Basically, this new feature makes it easier to query data in tables as if it were in a graph database, providing a possibly more intuitive alternative to writing complex join queries.

There is an ongoing debate about which graph data model is best, and in this blog post, we’ll explore why RDF (Resource Description Framework) stands out as the superior choice for building more sustainable and scalable knowledge graphs over LPG (Labeled Property Graphs).

Copyleft Richard Towers 2025. All wrongs reserved.

Temporal databases are in contrast to current databases (not to be confused with currently available databases), which store only facts which are believed to be true at the current time.

I've never written an IMDB review before but am provoked to do so by the current rating of 5.8,

79 View upvote and downvote totals. This answer is not useful Save this answer. Show activity on this post. Generally, there is no downside to using text in terms of performance/memory. On the contrary: text is the optimum. Other types have more or less relevant downsides. text is literally the "preferred" type among string types in the Postgres type system, which can affect function or operator type resolution.

Don't add a length modifier to varchar if you don't need it. (Most of the time, you don't.) Just use text for all character data. Make that varchar (standard SQL type) without length modifier if you need to stay compatible with RDBMS which don't have text as generic character string type.

I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.

Page not found This question was removed from Stack Overflow for reasons of moderation. Please refer to the help center for possible explanations why a question might be removed.

With its "no downstream hacks" and "upstream first" approach, it acts as a cutting-edge catalyst to push open-source technologies we love forward.

The problem with returning a generic error message for the user is a User Experience (UX) matter. A legitimate user might feel confused with the generic messages, thus making it hard for them to use the application, and might after several retries, leave the application because of its complexity. The decision to return a generic error message can be determined based on the criticality of the application and its data. For example, for critical applications, the team can decide that under the failure scenario, a user will always be redirected to the support page and a generic error message will be returned.

Using any of the authentication mechanisms (login, password reset, or password recovery), an application must respond with a generic error message regardless of whether: The user ID or password was incorrect. The account does not exist. The account is locked or disabled.

Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration. An application should respond (both HTTP and HTML) in a generic manner.

Authentication (AuthN) is the process of verifying that an individual, entity, or website is who or what it claims to be by determining the validity of one or more authenticators (like passwords, fingerprints, or security tokens) that are used to back up this claim.

ChildOf

Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP),

t.column :created_at, :timestamptz, null: false

Traditional, server-side web applications have traditionally used cookie-based authentication.

Token-based authentication

family_name string Surname(s) or last name(s) of the End-User. Note that in some cultures, people can have multiple family names or no family name; all can be present, with the names being separated by space characters.

given_name string Given name(s) or first name(s)

OIDC refresher: OpenID Connect is an identity protocol built on top of the OAuth 2.0 framework. If a request scope of OIDC is defined when initiating an OAuth flow, identity providers present the application an ID token along with an access token on a successful sign-in. The ID token is a JWT that contains some user information like name, email, and avatar, in the form of “claims”.

Clerk’s SSO uses the Open ID Connect protocol (OIDC), which provides an email_verified claim. Identity Providers are supposed to set this to true if they have verified the user’s email. Almost every SSO provider verifies emails, so if a user signs up with a social provider, a second email verification step is unnecessary.

The JWT carries the signup attempt information and is only valid for 10 minutes

It’s used during sign-in: as a workaround to forgotten password, or as an alternative to passwords altogether.

It’s used during sign-up: usually to prevent spam accounts, or as a requirement before enrolling a user on a mailing list.

Email verification is a foundational and reusable piece of modern authentication:

We could require email verification as soon as a user signs up, or perhaps when the user comes back for the second session. Shifting the onboarding friction from email verification to a later time can make the process much more natural for users. For example, a social media platform can minimize friction during the sign up process so that a user can immediately start to consume content. Later, when the user wants to post content, the platform can verify emails to minimize spam.

CSRF protection is a must when using cookies. A very simple way to prevent CSRF attacks is to check the Origin header for non-GET requests.

That’s a codebase first approach

You have your TypeScript Drizzle schema as a source of truth

You have your database schema as a source of truth

In PostgreSQL, there is an entity called a schema (which we believe should be called folders).

Fork your own copy of drizzle-kit and update src/serializer/pgSerializer.ts

Modify your local node_modules/drizzle-kit/bin.cjs file and modify line

Supabase is a hosted platform. You can sign up and start using Supabase without installing anything. You can also self-host and develop locally.

If I can get some support from the maintainere, sure. I think they are all unavailable these days though. The review queue is now 200+ PRs deep. I'll probably make a fork for myself until this gets prioritized.

With Vitest you get to define the configuration for your dev, build and test environments as a single pipeline, sharing the same plugins and the same vite.config.js.

Vitest aims to position itself as the Test Runner of choice for Vite projects, and as a solid alternative even for projects not using Vite.

I'm going to give it a 10 just because the IMDb rating for this film is so surprisingly low. It deserves a higher rating.

By which I mean, don’t do it.

The solution is to not do this. When working with fenced code blocks, do not indent them. This isn’t an issue that can really be worked around, even if the parser did make assumptions about what you meant. Because code blocks are designed to respect whitespace, any fix would simply result in a different but equally frustrating failure. Don’t indent code blocks.

mdsvex is a markdown preprocessor for Svelte components. Basically MDX for Svelte.

init runs an init process (PID 1) inside the container that forwards signals and reaps processes

tini is pretty minimal overhead and widely used, so why not use --init most of the time?

For more details see this github comment which answers the "why?" question from the creator of tini.

When to use an init

The other role an init process can provide is to install signal handlers so signals sent from the host can be passed onto the container process. PID 1 is a bit special as it requires the process to listen for a signal for it to be received.

The first thing to understand is an init process doesn't magically remove zombies. A (normal) init is designed to reap zombies when the parent process that failed to wait on them exits and the zombies hang around. The init process then becomes the zombies parent and they can be cleaned up.

The solution is to use docker run --init to run an init process as PID 1, that will take care of propagating the signals to the other processes, it is safe enough to be used basically always.

Today I realized that the pursuit of knowledge is a lifelong journey. It’s important to question what we know to avoid biases.

It protects you from software that accidentally creates zombie processes, which can (over time!) starve your entire system for PIDs (and make it unusable).

It ensures that the default signal handlers work for the software you run in your Docker image. For example, with Tini, SIGTERM properly terminates your process even if you didn't explicitly install a signal handler for it.

If you are using Docker 1.13 or greater, Tini is included in Docker itself. This includes all versions of Docker CE. To enable Tini, just pass the --init flag to docker run.

reaping zombies

performing signal forwarding

Event handlers are now just props like any other, making it easy to (for example) know whether the user of your component supplied a particular event handler (which can be useful for avoiding expensive setup work), or to spread arbitrary event handlers onto some element — things that are particularly important for library authors.

This bug will be marked as "Depends on" bugs that are needed to complete implementation of css-view-transitions-1. The dependency tree can be used to view a list of these dependencies. Please do not add comments about specific issues to this bug; they belong in their own bugs.

As is fairly typical for documentary films on such emotive subjects, people who agree with the filmmaker's point of view rate it highly and rave about the film's objectivity while those who are predisposed against that point of view disparage it as industry propaganda and attack the credibility of the filmmakers.

WebScrapBook 2.12.0 has reworked the strategy of handling constructed stylesheets so that they don't duplicate among each referenced shadow DOMs anymore.

In my experience, I have found that using the SingleFile chrome extension does exactly the task that I'm after (almost), and it does it best. It's able to save the page precisely as it looks like to the user during a live render (even when viewed offline), and I've found that it's better than both the "Save Page WE" and the "WebScrapBook" extensions.

but that simply just launches a headless browser and downloads the requested URL. This approach is useless in my case since I want to save the Reddit page with the modifications that I've personally and manually made (i.e., with the desired comment threads manually expanded).

<Image /> and <Picture /> components are unavailable in .md files.

Starlight provides a custom Markdown syntax for rendering asides. Aside blocks are indicated using a pair of triple colons ::: to wrap your content, and can be of type note, tip, caution or danger.

At present, I don’t have the bandwidth to maintain 2 reference parsers and a spec.

Autolinks do not work in MDX. The reason is that they can be indistinguishable from JSX (for example: <svg:rect>) and we prefer being explicit. If you want links, use full links: [descriptive text](https://and-the-link-here.com)

The reason for that is so you can nicely indent your components:

Markdown often feels more natural to type than HTML or JSX for common things like emphasis or headings. Markdown typically looks more like what’s intended and is terser.

Much later followup-

Over the years I found the MHTML format faster to acquire (there’s no messing around with the pdf output formatting options (header, pagination, etc)) and it’s much faster to reload on later viewings .

Browser add-on: Save Page WE Firefox / Chrome A firefox/chrome add-on which is lighter than the web-recorder mentioned below, and which worked well for a subset of use cases. Configurable, flexible, and can optionally scroll pages in order to retrieve lazy-loaded content. It inlines images, scripts, fonts, etc as data-URLs producing a single big standalone HTML file.

It's not possible to do this with many websites these days. And for sites that seem like it's possible, it would still require some Javascript experience for reverse-engineering and "fixing" the scripts that are saved to your computer. There is no single method that works for all websites, you have to work through each unique problem for every site you try to save.

I tested it and it works, but be careful, there is no source code I can see and to modify headers you need full permissions on all pages. You can also enable/disable it from Firefox add-on manager, as needed.

Think of a client island as an interactive widget floating in a sea of otherwise static, lightweight, server-rendered HTML. Server islands can be added for personalized or dynamic server-rendered elements, such as a logged in visitor’s profile picture.

One of our favorite sayings is: opt in to complexity. We designed Astro to remove as much “required complexity” as possible from the developer experience, especially as you onboard for the first time. You can build a “Hello World” example website in Astro with just HTML and CSS. Then, when you need to build something more powerful, you can incrementally reach for new features and APIs as you go.

Astro was designed to be less complex than other UI frameworks and languages. One big reason for this is that Astro was designed to render on the server, not in the browser. That means that you don’t need to worry about: hooks (React), stale closures (also React), refs (Vue), observables (Svelte), atoms, selectors, reactions, or derivations. There is no reactivity on the server, so all of that complexity melts away.

By contrast, most modern web frameworks were designed for building web applications. These frameworks excel at building more complex, application-like experiences in the browser: logged-in admin dashboards, inboxes, social networks, todo lists, and even native-like applications like Figma and Ping. However with that complexity, they can struggle to provide great performance when delivering your content.

Access control works by registering the Pages daemon as an OAuth application with GitLab. Whenever a request to access a private Pages site is made by an unauthenticated user, the Pages daemon redirects the user to GitLab. If authentication is successful, the user is redirected back to Pages with a token, which is persisted in a cookie.