d5ede91a9fff7042b9085fe976a839996b5b850c
The mechanism paragraph said the server pair being refused is what lets the widget's partitioned pair land. That is false: CHIPS makes the partition key part of a cookie's identity, so the two are different cookies and coexist, and #2218 measured all four at once on Chromium. Firefox is the exception because Total Cookie Protection files the server cookie under the embedder's partition, which makes the keys collide, and a script may not replace an HttpOnly cookie it collides with. The section now reports the outcome per engine and stops asserting a causal link the measurements do not show. PartitionedCookies was called the better answer for either path with no limits attached. Two apply. The option is global, so Service.Set puts it on the OAuth callback too, and a cookie partitioned to the popup's own top-level context is one the frame cannot see, which regresses OAuth on the permissive browsers where it works today. And HttpOnly removes bearer-token theft, not authenticated action during an XSS, since the XSRF value stays readable by design and script on the widget origin can still make requests the browser attaches the cookie to. The evidence claim was broader than any single run supports. The criterion asks for sign-in, a post and a reload; the permanent suite does all three but only on Chromium's default policy against a stack that is not the recommended recipe, and the cross-browser campaign covered sign-in and reload on the recommended recipe without posting. Both halves are now stated. Also: 70 runnable top-level tests, not 71, which counted TestMain; and three engines across four browser targets, since Safari is a WebKit browser.
Fill the instance URL into the embedded frontend at serve time, and stop pinning compressor output in tests (#2198)
Fill the instance URL into the embedded frontend at serve time, and stop pinning compressor output in tests (#2198)
Fill the instance URL into the embedded frontend at serve time, and stop pinning compressor output in tests (#2198)
Remark42

Remark42 is a self-hosted, lightweight and simple (yet functional) comment engine, which doesn't spy on users. It can be embedded into blogs, articles, or any other place where readers add comments.
- Social login via Google, Facebook, Microsoft, GitHub, Apple, Yandex, Patreon, Discord, Telegram and custom OAuth2 providers
- Login via email
- Optional anonymous access
- Multi-level nested comments with both tree and plain presentations
- Import from Disqus and WordPress
- Markdown support with friendly formatter toolbar
- Moderator can remove comments and block users
- Voting, pinning and verification system
- Sortable comments
- Images upload with drag-and-drop
- Extractor for recent comments, cross-post
- RSS for all comments and each post
- Telegram, Slack, Webhook and email notifications for Admins (get notified for each new comment)
- Email and Telegram notifications for users (get notified when someone responds to your comment)
- Export data to JSON with automatic backups
- No external databases, everything embedded in a single data file
- Fully dockerized and can be deployed in a single command
- Self-contained executable can be deployed directly to Linux, Windows and macOS
- Clean, lightweight and customizable UI with white and dark themes
- Multi-site mode from a single instance
- Integration with automatic SSL (direct and via nginx-le)
- Privacy focused
Demo site available with all authentication methods, including email auth and anonymous access.
All remark42 documentation is available by the link.
Contribution
In order to start and work on the project locally in development mode check our contribution documentation for backend and frontend.
If you are interested in adding a new localization please check these docs.
Related projects
Languages
Go
69.4%
TypeScript
22.8%
CSS
3.2%
HTML
1.3%
JavaScript
1.3%
Other
2%
