<feed xmlns='http://www.w3.org/2005/Atom'>
<title>progmaweb/ops/README.md, branch feature/remove-xide</title>
<subtitle>The site and account service of Progmasoft: a Next.js frontend and an ASP.NET Core API.</subtitle>
<link rel='alternate' type='text/html' href='https://git.progmasoft.com/progmaweb/'/>
<entry>
<title>Remove Xide and ides.progmasoft.com</title>
<updated>2026-11-08T15:46:08+00:00</updated>
<author>
<name>Leitwolf11</name>
</author>
<published>2026-11-08T15:46:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.progmasoft.com/progmaweb/commit/?id=efa1f584205e93c292ea40b564d92a03f12ab33c'/>
<id>efa1f584205e93c292ea40b564d92a03f12ab33c</id>
<content type='text'>
Xide is no longer developed as of 2026-11-08 (Progmasoft/xide#29), so
Progmaweb stops presenting it:

- product.progmasoft.com: Xide leaves the catalog, its card and its
  detail page; /xide on the product host is a 404 like any unknown
  product. The catalog's description in every language names the Tala
  language with its tools and Catch3.
- ides.progmasoft.com served only the IDE list and the Xide page, so the
  whole site goes: the pages under app/ides, its texts in every
  language, idesRoute and its host in the proxy, and both nginx server
  blocks. The certificate of progmasoft.com no longer has to name it.

Tests: the catalog lists the remaining products and refuses xide.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Xide is no longer developed as of 2026-11-08 (Progmasoft/xide#29), so
Progmaweb stops presenting it:

- product.progmasoft.com: Xide leaves the catalog, its card and its
  detail page; /xide on the product host is a 404 like any unknown
  product. The catalog's description in every language names the Tala
  language with its tools and Catch3.
- ides.progmasoft.com served only the IDE list and the Xide page, so the
  whole site goes: the pages under app/ides, its texts in every
  language, idesRoute and its host in the proxy, and both nginx server
  blocks. The certificate of progmasoft.com no longer has to name it.

Tests: the catalog lists the remaining products and refuses xide.
</pre>
</div>
</content>
</entry>
<entry>
<title>Make the policies say what ViGet and support do today</title>
<updated>2026-11-06T12:00:16+00:00</updated>
<author>
<name>Leitwolf11</name>
</author>
<published>2026-11-06T12:00:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.progmasoft.com/progmaweb/commit/?id=8f7f90b57ecc0bf5fba555b389c149ac068929b0'/>
<id>8f7f90b57ecc0bf5fba555b389c149ac068929b0</id>
<content type='text'>
The review found four promises the policies made beyond what exists:

- ViGet takes no uploads from accounts yet; only Progmasoft publishes,
  through a server command. The Privacy Policy now says so, and that
  ViGet will record the IP address of each upload, for that one purpose
  and for the same time, once uploads open. ops/README.md tells the
  upload endpoint to do exactly that.
- A yank leaves a JAR served by nginx and cached by Cloudflare for a
  year. The Security Policy says a malicious version is taken off ViGet
  and kept out of reach as evidence; ops/README.md gives the four steps:
  yank, move the JAR into a root-only quarantine, purge the Cloudflare
  cache, close the account.
- The API cannot delete an account. ops/README.md gives the procedure
  support follows on a request from the account's address: a dump, then
  one transaction that removes the OpenIddict tokens and authorizations
  of the account, the applications it alone owns, and the account with
  its sessions and ownerships.
- Pages allow Cloudflare's analytics script besides their own, and the
  Security Policy now names it.

ops/README.md also records the nginx logs without client addresses on
both servers, which make the Privacy Policy's statement about web-server
logs true.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The review found four promises the policies made beyond what exists:

- ViGet takes no uploads from accounts yet; only Progmasoft publishes,
  through a server command. The Privacy Policy now says so, and that
  ViGet will record the IP address of each upload, for that one purpose
  and for the same time, once uploads open. ops/README.md tells the
  upload endpoint to do exactly that.
- A yank leaves a JAR served by nginx and cached by Cloudflare for a
  year. The Security Policy says a malicious version is taken off ViGet
  and kept out of reach as evidence; ops/README.md gives the four steps:
  yank, move the JAR into a root-only quarantine, purge the Cloudflare
  cache, close the account.
- The API cannot delete an account. ops/README.md gives the procedure
  support follows on a request from the account's address: a dump, then
  one transaction that removes the OpenIddict tokens and authorizations
  of the account, the applications it alone owns, and the account with
  its sessions and ownerships.
- Pages allow Cloudflare's analytics script besides their own, and the
  Security Policy now names it.

ops/README.md also records the nginx logs without client addresses on
both servers, which make the Privacy Policy's statement about web-server
logs true.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge remote-tracking branch 'origin/main' into feature/provision-reserved-accounts</title>
<updated>2026-10-29T12:52:11+00:00</updated>
<author>
<name>Leitwolf11</name>
</author>
<published>2026-10-29T12:52:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.progmasoft.com/progmaweb/commit/?id=3749e30da561652a226017d9360b84e34a8b74fc'/>
<id>3749e30da561652a226017d9360b84e34a8b74fc</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Provision the reserved accounts on the server</title>
<updated>2026-10-29T12:35:06+00:00</updated>
<author>
<name>Leitwolf11</name>
</author>
<published>2026-10-29T12:35:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.progmasoft.com/progmaweb/commit/?id=21b515565b73f86477afe436bb3588f3e5929443'/>
<id>21b515565b73f86477afe436bb3588f3e5929443</id>
<content type='text'>
Registration refuses the reserved names Progmasoft and Leitwolf, which are
meant to be created by trusted operations tooling only, and that tooling did
not exist: the Progmasoft account, the publisher of Progmasoft's Tazel
plugins on ViGet, could not be created at all.

- 'accounts provision-reserved &lt;Name&gt; &lt;email&gt;' runs with the configuration
  of the service, like the viget commands. It accepts only the reserved
  names, applies the rules of registration to the email address and the
  password, never replaces an existing account, and brings the account
  tables to the current schema first.
- The password is read from the terminal without echo, twice, or from one
  line of standard input when it is not a terminal; it never appears on a
  command line or in the output.
- AccountNamePolicy.TryNormalizeReserved checks a reserved name;
  TryNormalize, which registration uses, still refuses it.

Tests cover a reserved account created and signing in with its password,
a name that is not reserved, two different passwords, a weak password, an
existing account and the usage line. ops/README.md shows the command with
systemd-run --pty; docs/ACCOUNT-API.md points to it.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Registration refuses the reserved names Progmasoft and Leitwolf, which are
meant to be created by trusted operations tooling only, and that tooling did
not exist: the Progmasoft account, the publisher of Progmasoft's Tazel
plugins on ViGet, could not be created at all.

- 'accounts provision-reserved &lt;Name&gt; &lt;email&gt;' runs with the configuration
  of the service, like the viget commands. It accepts only the reserved
  names, applies the rules of registration to the email address and the
  password, never replaces an existing account, and brings the account
  tables to the current schema first.
- The password is read from the terminal without echo, twice, or from one
  line of standard input when it is not a terminal; it never appears on a
  command line or in the output.
- AccountNamePolicy.TryNormalizeReserved checks a reserved name;
  TryNormalize, which registration uses, still refuses it.

Tests cover a reserved account created and signing in with its password,
a name that is not reserved, two different passwords, a weak password, an
existing account and the usage line. ops/README.md shows the command with
systemd-run --pty; docs/ACCOUNT-API.md points to it.
</pre>
</div>
</content>
</entry>
<entry>
<title>Publish ViGet plugins without putting the environment on a command line</title>
<updated>2026-10-29T12:04:15+00:00</updated>
<author>
<name>Leitwolf11</name>
</author>
<published>2026-10-29T12:04:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.progmasoft.com/progmaweb/commit/?id=e644c9bb28ca59d93f09c2d732aa7f070ecdaf21'/>
<id>e644c9bb28ca59d93f09c2d732aa7f070ecdaf21</id>
<content type='text'>
The documented command passed the variables of account.env to env as
arguments, which shows them in the process list to every user while it
runs. systemd-run reads the environment file itself, runs as the service
user with the production environment, and the JAR goes through a private
incoming directory. The publisher must be an existing account.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The documented command passed the variables of account.env to env as
arguments, which shows them in the process list to every user while it
runs. systemd-run reads the environment file itself, runs as the service
user with the production environment, and the JAR goes through a private
incoming directory. The publisher must be an existing account.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Show the Tazel plugins of ViGet, open the Gradle catalog, and route their files</title>
<updated>2026-10-29T09:32:23+00:00</updated>
<author>
<name>Leitwolf11</name>
</author>
<published>2026-10-29T09:32:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.progmasoft.com/progmaweb/commit/?id=3d1c6d52b830d201a68b0440a8a81c13b74c8b92'/>
<id>3d1c6d52b830d201a68b0440a8a81c13b74c8b92</id>
<content type='text'>
The API of the previous commit holds the catalog; this adds what people and
Tazel reach.

Pages:
- /dslplugins/tazel lists the published plugins, read from the API on its
  loopback address, and says when there is none.
- /dslplugins/tazel/&lt;Publisher&gt;/&lt;Name&gt; is the page of a plugin: its
  description, publisher, latest version, license, authors, homepage and
  repository, the plugins block that uses it, and every version with its
  date, plugin API, size, SHA-256, yanked mark and JAR.
- /dslplugins/gradle opens the Gradle catalog. It only lists: Gradle takes
  com.progmasoft.tazel.plugin from the Gradle Plugin Portal.
- The availability note says that Progmasoft publishes first and every
  account later. Texts are in the four languages of the site.

Nginx (ops/nginx/progmaweb.conf):
- On viget.progmasoft.com, index.json of a plugin goes to the API and the
  JARs come from /srv/viget/files with immutable caching; /api/ stays
  closed.
- maven.progmasoft.com serves /srv/maven, whose /tazel holds tazel-api.

ops/README.md describes the directories, their SELinux labels, the publish
and yank commands, and how a release of Tazel copies the API into the Maven
repository.

Tests cover the texts in every language, the plugins block, the Gradle list,
and that a page asks the API only for identifiers.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The API of the previous commit holds the catalog; this adds what people and
Tazel reach.

Pages:
- /dslplugins/tazel lists the published plugins, read from the API on its
  loopback address, and says when there is none.
- /dslplugins/tazel/&lt;Publisher&gt;/&lt;Name&gt; is the page of a plugin: its
  description, publisher, latest version, license, authors, homepage and
  repository, the plugins block that uses it, and every version with its
  date, plugin API, size, SHA-256, yanked mark and JAR.
- /dslplugins/gradle opens the Gradle catalog. It only lists: Gradle takes
  com.progmasoft.tazel.plugin from the Gradle Plugin Portal.
- The availability note says that Progmasoft publishes first and every
  account later. Texts are in the four languages of the site.

Nginx (ops/nginx/progmaweb.conf):
- On viget.progmasoft.com, index.json of a plugin goes to the API and the
  JARs come from /srv/viget/files with immutable caching; /api/ stays
  closed.
- maven.progmasoft.com serves /srv/maven, whose /tazel holds tazel-api.

ops/README.md describes the directories, their SELinux labels, the publish
and yank commands, and how a release of Tazel copies the API into the Maven
repository.

Tests cover the texts in every language, the plugins block, the Gradle list,
and that a page asks the API only for identifiers.
</pre>
</div>
</content>
</entry>
<entry>
<title>Redesign progmasoft.com and add the product catalog and product sites</title>
<updated>2026-10-23T08:29:43+00:00</updated>
<author>
<name>Leitwolf11</name>
</author>
<published>2026-10-23T08:29:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.progmasoft.com/progmaweb/commit/?id=20a55c4ccbb0f181346444a4c7f083e86389cf9c'/>
<id>20a55c4ccbb0f181346444a4c7f083e86389cf9c</id>
<content type='text'>
progmasoft.com presents Progmasoft as a pool of technology areas instead
of a list of products: languages and compilers, build and packages,
developer tools, quality and testing, identity and access, and
infrastructure. The page has a new hero, a bento of areas, principles and
a developers band that leads to the Progmasoft Console; the products are
one link away in their own catalog.

product.progmasoft.com lists Tala, talac, talafmt, talalint, Tazel, Xide
and Catch3, each with its own page (/tala-lang, /talac, ...) that leads
to the product's site and source. ides.progmasoft.com lists the IDEs and
hosts the Xide site at /xide; catch3.progmasoft.com is the Catch3 site.
The facts follow the READMEs and documentation of the product
repositories: Xide is marked as early work, and Catch3 states that it is
not an official Catch2 release.

The theme switch no longer freezes or flickers. The layout rendered
data-theme="light" on &lt;html&gt;, so every server re-render of the layout
(a language switch) set it back. The control also applied the theme in
an effect after the render while buttons animated their colours. The
attribute now belongs to the bootstrap script and the control alone; the
control applies the theme in the click, and transitions are off for the
two frames of the change.

All new text is in en-US, de-DE, ru-RU and he-IL. The old home messages
leave localization.ts. The proxy maps the new hosts through one table, and
nginx gains their virtual hosts.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
progmasoft.com presents Progmasoft as a pool of technology areas instead
of a list of products: languages and compilers, build and packages,
developer tools, quality and testing, identity and access, and
infrastructure. The page has a new hero, a bento of areas, principles and
a developers band that leads to the Progmasoft Console; the products are
one link away in their own catalog.

product.progmasoft.com lists Tala, talac, talafmt, talalint, Tazel, Xide
and Catch3, each with its own page (/tala-lang, /talac, ...) that leads
to the product's site and source. ides.progmasoft.com lists the IDEs and
hosts the Xide site at /xide; catch3.progmasoft.com is the Catch3 site.
The facts follow the READMEs and documentation of the product
repositories: Xide is marked as early work, and Catch3 states that it is
not an official Catch2 release.

The theme switch no longer freezes or flickers. The layout rendered
data-theme="light" on &lt;html&gt;, so every server re-render of the layout
(a language switch) set it back. The control also applied the theme in
an effect after the render while buttons animated their colours. The
attribute now belongs to the bootstrap script and the control alone; the
control applies the theme in the click, and transitions are off for the
two frames of the change.

All new text is in en-US, de-DE, ru-RU and he-IL. The old home messages
leave localization.ts. The proxy maps the new hosts through one table, and
nginx gains their virtual hosts.
</pre>
</div>
</content>
</entry>
<entry>
<title>Move the OAuth pages to Next.js and split the authorize host and the console</title>
<updated>2026-10-23T08:02:39+00:00</updated>
<author>
<name>Leitwolf11</name>
</author>
<published>2026-10-23T08:02:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.progmasoft.com/progmaweb/commit/?id=9099e9fbb50d27b622362b0c2f0dda5085d1fa03'/>
<id>9099e9fbb50d27b622362b0c2f0dda5085d1fa03</id>
<content type='text'>
Progmasoft OAuth now runs on three hosts:

- credentials.progmasoft.com stays the issuer: discovery documents, key
  set, token, user information, revocation and introspection.
- authorize.progmasoft.com serves the pages people see: the
  authorization and end session endpoints (registered with OpenIddict as
  absolute URIs on that host), sign-in, the consent screen and the
  applications an account has allowed.
- console.progmasoft.com is the Progmasoft Console. Its overview links
  the areas; OAuth 2.1 tokens live under /credentials, with New token,
  then the application type, then its form.

The console has no sign-in of its own and never redirects. It uses the
Progmasoft account session, so production now shares that cookie with
progmasoft.com (__Secure-ProgmasoftSession, Domain=progmasoft.com,
HttpOnly, Secure, SameSite=Lax). Without AccountSessions:CookieDomain the
cookie stays host-only with the __Host- name, as in development and tests.

Application types replace the confidential/public switch: web,
single-page, desktop, mobile and service. Each type has its redirection
rules (RFC 8252), its secret or none, and its grants; only a service
uses client credentials and it registers no address or scope. The type is
kept as an application property and cannot change.

The HTML pages of the API are gone. The pages are Next.js pages in four
languages (en-US, de-DE, ru-RU, he-IL) that call JSON endpoints under
/api/v1/oauth. Requests that change state must come from the page's own
origin; antiforgery forms are no longer needed. The token, revocation and
user information endpoints answer CORS requests from the origins of
single-page applications, without credentials; the discovery documents
and the key set answer every origin.

The host filter keeps every path on its host. Nginx gains the authorize
and console virtual hosts, and the docs describe the hosts, the types and
the shared session.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Progmasoft OAuth now runs on three hosts:

- credentials.progmasoft.com stays the issuer: discovery documents, key
  set, token, user information, revocation and introspection.
- authorize.progmasoft.com serves the pages people see: the
  authorization and end session endpoints (registered with OpenIddict as
  absolute URIs on that host), sign-in, the consent screen and the
  applications an account has allowed.
- console.progmasoft.com is the Progmasoft Console. Its overview links
  the areas; OAuth 2.1 tokens live under /credentials, with New token,
  then the application type, then its form.

The console has no sign-in of its own and never redirects. It uses the
Progmasoft account session, so production now shares that cookie with
progmasoft.com (__Secure-ProgmasoftSession, Domain=progmasoft.com,
HttpOnly, Secure, SameSite=Lax). Without AccountSessions:CookieDomain the
cookie stays host-only with the __Host- name, as in development and tests.

Application types replace the confidential/public switch: web,
single-page, desktop, mobile and service. Each type has its redirection
rules (RFC 8252), its secret or none, and its grants; only a service
uses client credentials and it registers no address or scope. The type is
kept as an application property and cannot change.

The HTML pages of the API are gone. The pages are Next.js pages in four
languages (en-US, de-DE, ru-RU, he-IL) that call JSON endpoints under
/api/v1/oauth. Requests that change state must come from the page's own
origin; antiforgery forms are no longer needed. The token, revocation and
user information endpoints answer CORS requests from the origins of
single-page applications, without credentials; the discovery documents
and the key set answer every origin.

The host filter keeps every path on its host. Nginx gains the authorize
and console virtual hosts, and the docs describe the hosts, the types and
the shared session.
</pre>
</div>
</content>
</entry>
<entry>
<title>Add Progmasoft OAuth, an OAuth 2.1 and OpenID Connect provider</title>
<updated>2026-10-23T01:49:52+00:00</updated>
<author>
<name>Leitwolf11</name>
</author>
<published>2026-10-23T01:49:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.progmasoft.com/progmaweb/commit/?id=cffc8d884ce3620b70c80a9ab98b8f1f03887402'/>
<id>cffc8d884ce3620b70c80a9ab98b8f1f03887402</id>
<content type='text'>
Progmasoft accounts can now sign in to any application, and any
developer can register one. The provider runs in the account API under
the Progmasoft.OAuth namespaces and answers on credentials.progmasoft.com.

Protocol: OpenIddict 7 (Apache-2.0) with its Entity Framework stores.
Authorization code with PKCE for every client, S256 only; refresh
tokens with rotation and no reuse leeway, so a replayed refresh token
revokes its chain; client credentials for confidential clients, without
account scopes. No implicit or password grant. Codes live 2 minutes,
access and identity tokens 15 minutes, refresh tokens 30 days. Signing
(RSA) and encryption keys are read from files in production and are
required there; other environments make keys per process.

Scopes, one grant each, as the consent page lists them: profile (the
account name), email (the sign-in address; email_verified is false,
since registration does not verify it), viget.packages.read,
viget.packages.publish and viget.packages.yank (access tokens for the
viget audience), and offline_access.

Pages, plain HTML without script, behind a content security policy that
allows the one stylesheet by digest: sign-in with the account password
(a cookie of its own, no account-site session), consent with the
application, its registering account and the return host, the developer
portal (register confidential or public clients, redirect address rules
from RFC 8252, scopes, client credentials, secret shown once and
rotatable, delete; 10 applications per account; other accounts'
applications are absent), and the applications an account has allowed,
with withdrawal that revokes their tokens. Forms carry antiforgery
tokens; return addresses stay on the host.

Storage: the oauth_* tables in the account database, created by a
numbered schema step like the account tables; the step is the script
Entity Framework generates for the model, and a test compares the two.
With the memory account store they live in a shared in-memory SQLite
database, which runs the bulk revocations the in-memory provider cannot.

A host filter keeps OAuth paths on the OAuth host and everything but
OAuth and /health off it. AllowedHosts names the new host, and a rate
limit policy covers the protocol endpoints and the portal. The Nginx
vhost for the host and the key set-up are in ops; docs/OAUTH.md is the
developer guide.

AccountService gains VerifyPasswordAsync, which LoginAsync now uses,
and FindAsync.

Verified: dotnet build with warnings as errors; dotnet test, 125 tests,
109 passed and 16 PostgreSQL tests skipped locally (CI runs them,
including a new one for the schema and refresh token chain revocation):
code flow with PKCE and the claims of each scope, single-use codes,
refresh rotation and reuse refusal, consent reuse and withdrawal, deny,
public client with a private-use scheme, client credentials, ViGet
audience by introspection, refusal without PKCE, of other flows and of
unpermitted scopes, unregistered redirect addresses, sign-in redirects
and prompt=none, the portal's address rules and ownership, secret
rotation, the page security policy, the host filter and the discovery
document.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Progmasoft accounts can now sign in to any application, and any
developer can register one. The provider runs in the account API under
the Progmasoft.OAuth namespaces and answers on credentials.progmasoft.com.

Protocol: OpenIddict 7 (Apache-2.0) with its Entity Framework stores.
Authorization code with PKCE for every client, S256 only; refresh
tokens with rotation and no reuse leeway, so a replayed refresh token
revokes its chain; client credentials for confidential clients, without
account scopes. No implicit or password grant. Codes live 2 minutes,
access and identity tokens 15 minutes, refresh tokens 30 days. Signing
(RSA) and encryption keys are read from files in production and are
required there; other environments make keys per process.

Scopes, one grant each, as the consent page lists them: profile (the
account name), email (the sign-in address; email_verified is false,
since registration does not verify it), viget.packages.read,
viget.packages.publish and viget.packages.yank (access tokens for the
viget audience), and offline_access.

Pages, plain HTML without script, behind a content security policy that
allows the one stylesheet by digest: sign-in with the account password
(a cookie of its own, no account-site session), consent with the
application, its registering account and the return host, the developer
portal (register confidential or public clients, redirect address rules
from RFC 8252, scopes, client credentials, secret shown once and
rotatable, delete; 10 applications per account; other accounts'
applications are absent), and the applications an account has allowed,
with withdrawal that revokes their tokens. Forms carry antiforgery
tokens; return addresses stay on the host.

Storage: the oauth_* tables in the account database, created by a
numbered schema step like the account tables; the step is the script
Entity Framework generates for the model, and a test compares the two.
With the memory account store they live in a shared in-memory SQLite
database, which runs the bulk revocations the in-memory provider cannot.

A host filter keeps OAuth paths on the OAuth host and everything but
OAuth and /health off it. AllowedHosts names the new host, and a rate
limit policy covers the protocol endpoints and the portal. The Nginx
vhost for the host and the key set-up are in ops; docs/OAUTH.md is the
developer guide.

AccountService gains VerifyPasswordAsync, which LoginAsync now uses,
and FindAsync.

Verified: dotnet build with warnings as errors; dotnet test, 125 tests,
109 passed and 16 PostgreSQL tests skipped locally (CI runs them,
including a new one for the schema and refresh token chain revocation):
code flow with PKCE and the claims of each scope, single-use codes,
refresh rotation and reuse refusal, consent reuse and withdrawal, deny,
public client with a private-use scheme, client credentials, ViGet
audience by introspection, refusal without PKCE, of other flows and of
unpermitted scopes, unregistered redirect addresses, sign-in redirects
and prompt=none, the portal's address rules and ownership, secret
rotation, the page security policy, the host filter and the discovery
document.
</pre>
</div>
</content>
</entry>
<entry>
<title>Return a failed Google callback to sign-in and correct stale statements</title>
<updated>2026-10-16T03:00:57+00:00</updated>
<author>
<name>Leitwolf11</name>
</author>
<published>2026-10-16T03:00:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.progmasoft.com/progmaweb/commit/?id=bc653270652c1ab44d2144ddd17ae49b404e7cd2'/>
<id>bc653270652c1ab44d2144ddd17ae49b404e7cd2</id>
<content type='text'>
A Google callback that could not finish ended in an unhandled 500: a
visitor who declined on Google's consent screen, a callback whose state
cookie had expired, and a direct request to the callback path all got an
empty error page. The account API document already promised a redirect
to /login?google=failed for a failed callback; the handler of the Google
scheme now does that through OnRemoteFailure. Three new tests cover a
callback without state, a declined consent and a forged state.

Three statements no longer matched the sites:

- the bug report template still named the catalog paths without the
  language and the build system; they are /langs/tala/&lt;Publisher&gt;/&lt;Name&gt;/
  and /dslplugins/tazel/&lt;Publisher&gt;/&lt;Name&gt;/;
- the operations guide placed Tala content on xsharp-lang.xyz, which only
  redirects to tala.run now;
- the architecture guide described the ViGet routing before the catalogs
  per language and build system: it now gives the rewrites of /langs/tala
  and /dslplugins/tazel, the redirects of /langs and /dslplugins, three
  indexed ViGet pages and a sitemap with the home page and both catalogs.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A Google callback that could not finish ended in an unhandled 500: a
visitor who declined on Google's consent screen, a callback whose state
cookie had expired, and a direct request to the callback path all got an
empty error page. The account API document already promised a redirect
to /login?google=failed for a failed callback; the handler of the Google
scheme now does that through OnRemoteFailure. Three new tests cover a
callback without state, a declined consent and a forged state.

Three statements no longer matched the sites:

- the bug report template still named the catalog paths without the
  language and the build system; they are /langs/tala/&lt;Publisher&gt;/&lt;Name&gt;/
  and /dslplugins/tazel/&lt;Publisher&gt;/&lt;Name&gt;/;
- the operations guide placed Tala content on xsharp-lang.xyz, which only
  redirects to tala.run now;
- the architecture guide described the ViGet routing before the catalogs
  per language and build system: it now gives the rewrites of /langs/tala
  and /dslplugins/tazel, the redirects of /langs and /dslplugins, three
  indexed ViGet pages and a sitemap with the home page and both catalogs.
</pre>
</div>
</content>
</entry>
</feed>
