Those are cute... I see lots and lots of them impinging on my servers too. That's why I think it is important to have a processing step ahead of anything heavy that can reject stuff like that
Feb 15 20:03:17 make trinity: 184.108.40.206 - [15/Feb/2022:20:03:17 +00:00] "POST 220.127.116.11:/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 404 683 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
(defmethod reject-ip-request () (when *request* (let ((server (request-server-name *request*)) (path (request-uri *request*))) (when (or (not (stringp server)) (not (stringp path)) (and (?ip-address server)(not (string= path "/")))) (throw-code 404)))))
It'd be great to keep current panels at the same time slot. I'd suggest 14:00 UTC... Keeping the following in mind:
Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
The Authentication Panel has been incubating the Solid-OIDC specification for the last several years. Today was an important milestone in that the panel has voted to promote Solid-OIDC from a purely "editors draft" document to a Community Group Draft: roughly equivalent to a FPWD. A repository tag was created with the version number of this draft. This is all in preparation for a summertime target of ~CR status.
At present, the Solid-OIDC draft specification is available at https://solid.github.io/solid-oidc/ via a GitHub pages workflow. I would like to discuss how we can start moving these drafts into the https://solidproject.org/TR/ namespace, presumably under
oidc. Ideally, we will have an automated process via GH, but for now a manual process should suffice.
What would be the best way to proceed here?
@acoburn If you'd like to publish the CG-DRAFT at https://solidproject.org/TR/solid-oidc and https://solidproject.org/TR/2022/solid-oidc-20220328 (with links referring to each other and possibly including links to the ED) then please make a PR of the final HTML and scripts/media to the solid/specification repository .
On a related note, you may want to note solid/solid-oidc#98
@jeff-zucker I think we can make that more clear.
The understanding/agreement was that 2xx responses MUST include the Link header with pim:Storage. Normally - or is it just in my head? - 4xx - more interestingly 401/403 - shouldn't include information in the headers that reveal the semantics of the target resource. However, there are/may be exceptions in that in order to enable a feature (for clients) with minimal information, e.g., discovery of root contain/storage, through URL path hierarchy, we'd need the Link header with pim:Storage irrespective of the status code.
The way I interpret the current text - that I wrote - is that the header is always included.
I'd like to hear from server/application implementers. Is your server exposing the header at all times or limited to certain requests/responses? For Storage locations besides the root URL path (
/ after authority:port) I can't see how clients can work out a URI is allocated to identify the storage.
webidand the app by
WebID-TLS is defined in https://www.w3.org/2005/Incubator/webid/spec/tls/, which is independent of Solid. It is also an editor's draft so the same caveats as with the WebID spec itself apply. The Solid Protocol spec refers to WebID-TLS non-normatively at https://solidproject.org/TR/protocol#webid-tls
Historically, there have been implementations of this. I am not aware of any that are in active development, but that doesn't mean that there are not any