From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by mail.toke.dk (Postfix) with ESMTPS id 3CD5BA94F73 for ; Sun, 03 Nov 2024 19:21:31 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=Y9A85dTd Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5c984352742so4121976a12.1 for ; Sun, 03 Nov 2024 10:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730658090; x=1731262890; darn=lists.galene.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=2QyrZoj8+K8RN6cfPqfM8pSzX20dlPL3lhHVJmj27vU=; b=Y9A85dTdSYE/gkgqakCnpZM5VQegWheyJLOp9JB7vx9J0XTZqqsJT83L4yGwepobgr fB5WWMSBeX4L6mZqzMAK4qTWVgDb4UBoo1RmnV7G/MV+69SSKxqrhiq1ZrZbpDFh2KlC pEwnyz6sTqz8Mj/4fjxofZUn5NL8De8mrRcrOWjYH7s/zmkDl0fNX5pgEzAz2FPfYVM5 lsp9nBqF1EB4px+nfJ6tyW4o0gZCV8fC4yFmmmZoM2eWIrqtWkISnWAyf/Yt1YrSWurn E5PnKgmVdFOalLszG9R6afMKVYYwM8710O7f4nX1V5QJveq2+ftDkAz0/DqJi0DIFdww oXhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730658090; x=1731262890; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=2QyrZoj8+K8RN6cfPqfM8pSzX20dlPL3lhHVJmj27vU=; b=bfDm7RDR0icewipoo1gwznwiUwSrCt6wEkbGIR/Tdmz1GE4TT9yfwmaa7CYkhtgQAb 1XjKzKg4lEpBE/2xMGa+fO42GtS60TxuW0Nni5tSZVhO7L7ZnTM2BhStKPaD67AF95ts rT3E+52ai+9pDFB6PnH5O9qXRF/tv+DgNNqkGAaayx73WrwKmoV018STmbKXLMRajzxe NMbJpRBsedGoBAyJSASuu4LF+xuwLye9VB3UvZJwuFyIRwwqhiLPRgitUQMTkm6hWRkE +hW29zsakhgvlBdLPfuiaVHNdWeZg8zvlXXl8WQZ3qUTqnkd+ge0/BPwD+Z9gi6K9SL1 b3Mw== X-Gm-Message-State: AOJu0Yy1TRlhGWWXbGDpE3eDgLmL6fhjlRt3/ITNjlDBWoH2zQ1IvXbj GWl/XbZM9F2LLRA03MZuq4n7vB4POqnr6ac9NLSsmq8aFq9oxQsaH5zdQ5WopWvj7jJM32ZcWsV XEfXtNWfKnXz8WFBO+BMTCHS+2hk/jQf6 X-Google-Smtp-Source: AGHT+IESBkDeCUWXFp5ECJXUBhXWNMJRlKw/wS30NEPEdw0vcJYnGeqdSAgbtjpMJQQRLTCz532Kao4GsH48bcZacBQ= X-Received: by 2002:a05:6402:4310:b0:5ce:cfeb:dd1 with SMTP id 4fb4d7f45d1cf-5cecfeb10ebmr2879304a12.36.1730658089809; Sun, 03 Nov 2024 10:21:29 -0800 (PST) MIME-Version: 1.0 From: Marty Betz Date: Sun, 3 Nov 2024 10:21:16 -0800 Message-ID: To: galene@lists.galene.org Content-Type: multipart/alternative; boundary="000000000000abca310626063c17" Message-ID-Hash: JJVW5FW3MMQCLKY44E2TOKEJNGXMW3VL X-Message-ID-Hash: JJVW5FW3MMQCLKY44E2TOKEJNGXMW3VL X-MailFrom: martybetz@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Galene] Re: CORS help needed List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000abca310626063c17 Content-Type: text/plain; charset="UTF-8" On 2024-11-03, Juliusz Chroboczek wrote: > Currently, Galene has a very primitive CORS configuration: either > publicServer is not set in the config file, in which case no CORS headers > are produced, or publicServer is set, in which case CORS headers allow > unrestricted access Because of required access to /public-group.json and /groups/groupname, your bundled clients are only functional because they live on the same domain as your server. I guess one could argue that administrative requests should only be allowed from a browser using these bundled example clients. Maybe all third party client implementations should need to access "admin" APIs from a site-generating server. (And thus, no CORS needed, and lessened XSS vulnerability.) So drawing a line between browser accessible API calls needing CORS, and those you'd prefer to be accessible only from server would definitely be useful. I'm just learning about Galene details. What are administrative interactions vs user interactions? Questions: 1. For instance, will third party clients often want CORS access to data like /public-groups.json? 2. Couldn't XSS allow for nefarious websocket listening and response? Does the signaling protocol not also contain "administrative" possibilities? Thank you, Marty --000000000000abca310626063c17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 2024-11-03, Juliusz Chroboczek wrote:
> Currently= , Galene has a very primitive CORS configuration: either
> publicServ= er is not set in the config file, in which case no CORS headers
> are= produced, or publicServer is set, in which case CORS headers allow
>= unrestricted access

Because of required access to /public-group.jso= n and /groups/groupname, your bundled clients are only functional because t= hey live on the same domain as your server.

I guess one could argue = that administrative requests should only be allowed from a browser using th= ese bundled example=C2=A0clients. Maybe all third party client implementati= ons should need to access "admin" APIs from a site-generating ser= ver. (And thus, no CORS needed, and lessened XSS vulnerability.)

So = drawing a line between browser accessible API calls needing CORS, and those= you'd prefer to be accessible only from server would definitely be use= ful.

I'm just learning about Galene details. What are administra= tive interactions vs user interactions?

Questions:
1. For instanc= e, will third party clients often want CORS access to data like /public-gro= ups.json?

2. Couldn't XSS allow for nefarious websocket listenin= g and response? Does the signaling protocol not also contain "administ= rative" possibilities?

Thank you,
Marty
--000000000000abca310626063c17--