- First commit to issue fork.
- @liampower opened merge request.
- Status changed to Needs review
almost 2 years ago 1:47pm 25 January 2023 - Status changed to Needs work
almost 2 years ago 2:55am 27 January 2023 - π¦πΊAustralia klonos 90% Melbourne, Australia - 10% Larissa, Greece
The code generally looks good, and I have tested this in simplytest.me with https://git.drupalcode.org/project/securitytxt/-/merge_requests/5.patch and confirmed that it works as expected:
- I navigated to admin
/config/system/securitytxt
- I added dummy input for the email and phone fields, since at least one contact method needs to be provided
- scrolled down and found the "Expires" fieldset
- the "Expire date" field, was marked as required π (since the RFC states that this is a requirement)
- the date was set to a year in the future π
- saved configuration
- I navigated to
/admin/config/development/configuration/single/export
and confirmed that the settings were saved - the expiration date was saved as a Unix timestamp π
- I then navigated to
/.well-known/security.txt
and the output as as expected (mostly):
Contact: security@example.com Contact: 123456789 Expires: 2024-01-27T02:37:37+00:00 Signature: https://master-k6xfydjaryuxcpxtpgvolwenkzysbfpd.tugboatqa.com/.well-known/security.txt.sig
I'm marking this as "Needs Work", since the standard requires this to be in ISO 8601.
- I navigated to admin
- π¦πΊAustralia klonos 90% Melbourne, Australia - 10% Larissa, Greece
...I've added a comment with a simple code suggestion to fix the date output according to the RFC expectation, but as I mentioned in my earlier comment, perhaps we should offer an option to be outputting the date in UTC instead of local time.
- π¨πSwitzerland berdir Switzerland
What adding a requirements check that alerts/warns if the expiration date is (about to) arrive? That could be monitored as well then.
- πΊπΈUnited States Kristen Pol Santa Cruz, CA, USA
I like @Berdir's suggestion to add logging and/or messages/alerts that it's going to expire soon... not sure that should be configurable but, if it is, it should default to being enabled which would require an update hook to enable it upon database update.
- Status changed to RTBC
over 1 year ago 1:53pm 10 July 2023 - π³π±Netherlands Lendude Amsterdam
According to the PHP docs DateTime::ATOM is ISO 8601 compliant where DateTime::ISO8601 isn't, see
https://www.php.net/manual/en/class.datetimeinterface.php#datetimeinterf...DATE_ISO8601 ISO-8601 (example: 2005-08-15T15:52:01+0000) Note: This format is not compatible with ISO-8601, but is left this way for backward compatibility reasons. Use DateTimeInterface::ISO8601_EXPANDED, DateTimeInterface::ATOM for compatibility with ISO-8601 instead. (ref ISO8601:2004 section 4.3.3 clause d)
So, the current date format in the patch seems to be correct. I think adding #8 sounds great, but could be a follow up issue, since according to https://securitytxt.org/ 'Expires' is now required I don't think we should block this on adding more features.
- Status changed to Needs work
over 1 year ago 2:10pm 10 July 2023 - π³π±Netherlands Lendude Amsterdam
Oops, bit to quick, this needs to update the config schema in config/schema/securitytxt.schema.yml
- Status changed to Needs review
over 1 year ago 2:28pm 10 July 2023 - π³π±Netherlands ralphvdhoudt
Added patch to be used together with 3371000. Just for convenience.
- Status changed to RTBC
over 1 year ago 12:08pm 18 July 2023 - π³π±Netherlands johan_vm Tilburg
Test Lendude's adjustments and in MR#5 works.
- First commit to issue fork.
-
VladimirAus β
committed 4c4261af on 8.x-1.x authored by
LiamPower β
Issue #3313164 by LiamPower, ralphvdhoudt, klonos, xxxherby, meder,...
-
VladimirAus β
committed 4c4261af on 8.x-1.x authored by
LiamPower β
- Status changed to Fixed
over 1 year ago 2:06pm 9 August 2023 - π¦πΊAustralia VladimirAus Brisbane, Australia
Thank you! Committed! π₯
Automatically closed - issue fixed for 2 weeks with no activity.