progmasoft.com/privacy and progmasoft.com/security publish the two policies in en-US, de-DE, ru-RU and he-IL, and the footer links both. The Privacy Policy says what an account keeps and that Progmasoft keeps an IP address for one purpose only: with a ViGet upload, to establish where an upload that turns out to be malicious software came from and to give it to the competent authorities. It says that no data, the IP address included, is sold, rented or traded. The Security Policy covers passwords, sessions, HTTPS, the ban on malicious software in ViGet and how to report a weakness. The registration form asks the person to accept both policies, and the API refuses a registration without that acceptance, with a password (acceptPolicies, a validation error of that field) or through Google: the start of a Google registration without acceptPolicies=true goes back to /register?google=policies-required, and the completion creates no account unless the authentication state carries the current version. An account keeps the version it accepted and the moment, in two new columns that schema step 2 adds; accounts created before it keep null. PolicyAcceptance.CurrentVersion and policyVersion on the web side name the same date, and a web test reads the C# constant to keep them equal.
Tazel takes A.B.C, then .D, .E and -METADATA if needed, so the descriptor check follows it.
Progmasoft's releases move to four numbers, and the plugins publish here.
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 <Name> <email>' 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.
ViGet opens in stages: first only Progmasoft publishes Tazel plugins, later every account. This adds the catalog and the server-side publishing for the first stage; nothing publishes through the API yet. - ViGet/: the catalog of Tazel plugins (in memory, or in PostgreSQL beside the accounts with its own numbered schema steps), the descriptor read from the JAR (META-INF/tazel-plugin.properties, with a reader of the Java properties format, and the ProjectPlugin service entry), and publishing: the publisher must be in ViGet:TazelPublishers (Progmasoft for now) and an existing account of that exact name, a version is never replaced, names that differ only in letter case are refused, and ViGet needs a description, an author and a license. The JAR is kept at dslplugins/tazel/<Publisher>/<Name>/<Version>/<Name>-<Version>.jar below ViGet:ArtifactRoot. - Read endpoints under /api/v1/viget/dslplugins/tazel: the list, a plugin, and index.json, the index Tazel reads. - 'viget publish-tazel-plugin <jar>' and 'viget yank-tazel-plugin' run with the configuration of the service instead of the service. - The account store can find an account by name. The pages, the Nginx routes and the deployment follow.
CodeQL flagged the withdraw endpoint: the authorization was looked up by the identifier in the address and then checked against the account. The endpoint now searches only the signed-in account's authorizations for that identifier and revokes the tokens by the identifier it found, so another account's allowance is never loaded. A test withdraws as another account and gets 404.
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.
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.
A failed Google callback has returned the visitor to /login?google=failed since the previous release, but nothing recorded why: a declined consent, an expired or missing state cookie and a forged request all looked the same, and the log of the service held no entry at all. GoogleSignInFailure now handles OnRemoteFailure. It writes one warning, event GoogleSignInFailed (id 5), with the cause: the error code Google reported, such as access_denied, or the reason the handler refused the callback, such as "The oauth state was missing or invalid." An error code is written only when it is a short run of letters, digits, '_', '-' and '.'; anything else from the query string is written as an unrecognized error. The authorization code, the state and tokens are never logged. The redirect is unchanged. Four new tests cover the entry, the redirect, an unusual error value and a refused state. The account API document describes the log entry.