Paddy
b848d6eab9
Step 4 of docs/calendar-auth-migration.md, and the close of
DEFERRED_SECURITY.md item 1: no calendar route reads sessionId/sessionKey from
the query string any more, so a live credential no longer travels through
access logs, browser history and Referer headers.
The four write routes sit behind requireAppAccess('calendar'), which also
narrows who may edit from "any activated @nachklang.art account" to an
explicit per-user permission. They answer 401 signed out and 403 without the
permission, where they previously answered 403 for both.
The three read routes cannot use the middleware: one URL serves an anonymous
visitor, an iCal subscription holding a shared password, and a signed-in
editor who should see drafts. They resolve the session optionally instead, and
a signed-in user without the calendar permission is treated as anonymous
rather than refused - so they keep the public calendar access anyone has.
That public calendar staying anonymous is load-bearing: nachklang.art reads it
to show the next upcoming event. It is now pinned at both the password-table
and the route level, and so is the rule that a shared password can never be
used to write.
credentials.service.ts loses its session half and becomes the password table
it always wanted to be. The shared passwords survive only for iCal clients,
which cannot send a cookie.
Writes record the author as an admin user id and no longer have a legacy int
to write, which is what migration 003 makes room for.
/calendar/users/* is left in place: nothing calls it and a session it mints
opens nothing, but they are still live password-accepting endpoints, so
removing them belongs with the rest of the legacy path in step 5.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
50 lines
2.1 KiB
TypeScript
50 lines
2.1 KiB
TypeScript
import {describe, expect, it, beforeEach} from 'vitest';
|
|
|
|
import * as CredentialService from '../../src/models/calendar/events/credentials.service.js';
|
|
|
|
/**
|
|
* The public calendar is read anonymously by nachklang.art to show the next
|
|
* upcoming event. That is a load-bearing property, not an accident: the step 4
|
|
* cutover moved every signed-in path onto session cookies and left these shared
|
|
* passwords behind only for iCal subscriptions, and the failure mode of getting
|
|
* it wrong is the public website silently losing its events feed.
|
|
*
|
|
* So this pins both halves: public needs nothing, and the restricted calendars
|
|
* still need something.
|
|
*/
|
|
describe('hasAccess', () => {
|
|
beforeEach(() => {
|
|
process.env.MEMBER_CREDENTIAL = 'member-secret';
|
|
process.env.CHOIR_CREDENTIAL = 'choir-secret';
|
|
process.env.MANAGEMENT_CREDENTIAL = 'management-secret';
|
|
});
|
|
|
|
it('lets anyone read the public calendar with no password at all', async () => {
|
|
await expect(CredentialService.hasAccess('public', '')).resolves.toBe(true);
|
|
});
|
|
|
|
it.each([
|
|
['members', 'member-secret'],
|
|
['choir', 'choir-secret'],
|
|
['management', 'management-secret'],
|
|
['birthdays', 'choir-secret']
|
|
])('refuses %s without the credential and allows it with one', async (calendar, secret) => {
|
|
await expect(CredentialService.hasAccess(calendar, '')).resolves.toBe(false);
|
|
await expect(CredentialService.hasAccess(calendar, 'wrong')).resolves.toBe(false);
|
|
await expect(CredentialService.hasAccess(calendar, secret)).resolves.toBe(true);
|
|
});
|
|
|
|
it('refuses an unknown calendar outright', async () => {
|
|
await expect(CredentialService.hasAccess('nope', 'member-secret')).resolves.toBe(false);
|
|
});
|
|
|
|
it('refuses a calendar whose credential is not configured', async () => {
|
|
// An unset MEMBER_CREDENTIAL must not become "any password works", and in
|
|
// particular must not become "an absent password works".
|
|
delete process.env.MEMBER_CREDENTIAL;
|
|
|
|
await expect(CredentialService.hasAccess('members', '')).resolves.toBe(false);
|
|
await expect(CredentialService.hasAccess('members', undefined as any)).resolves.toBe(false);
|
|
});
|
|
});
|