Feature: iCal link #216
Feature: iCal link #216
Conversation
An ical link is now available on /calendar.ics. It contains all the ctfs with their description and dates. This endpoint is protected with a token by default, the password can be changed/removed by the admin.
gen_random_bytes is more suited for crypto purpose
If it should be removed, this should be done in a seperate PR.
Adds /calendar.ics route to frontend Fixes changing the ical key slight frontend changes when displaying the ical link
This reduced code redundancy
* Fix eslint errors * Fix insecure randomness in Registration.vue
Note: Users can still send requests which yield garbage responses, but this is not a security vulnerability because these responses are only served to the requesting user
The next page arrow did not work but is now fixed. Also remove the sorting functionality since it does not work.
If you create a CTF which is in the past, it would appear at the bottom of the past CTF table until you refresh the table. Now the list is properly sorted which will place the CTF at the expected place.
This was newly added to the challenge categories as listed at https://ctf.hackthebox.com/api/public/challengeCategories
The graphql-upload packages has been swapped with graphql-upload-ts, because it is not possible anymore to use graphql-upload due to import issues.
The SCSS variables are from quasarframework/quasar#15144 (comment) This fixes the ugly dark shadows in dark mode but keeps the shadows in light mode. This was added in Quasar 2.11 but reverted using the SCSS patch. Due to an update of ESLint, it complains about single-word components. Since this is used in CTFNote, this rule is disabeld. Also some small (automatic) fixes.
It expects undefined officially, so we return that instead.
Now it uses the password-input just like the registration password.
The dialog UI is confusing because you think that the key is short but actually it is out of view in the input field. Since the only action is to get the link of the ical, we just copy it to the clipboard immediately and show a confirmation checkmark.
|
There were some merge conflicts with the |
|
@XeR Can you have a look please? ❤️ We'd like to use this feature! |
There was a problem hiding this comment.
Nice PR, but… 😄
I think we should not use a single shared token.
How do we invalidate a token when somebody leaves the team in bad terms?
Regenerating a token is doable, but it's a pain because everybody have to update everything.
What about $id:$hash instead ?
e.g. ?key=1337:deadbeefcafebabe… with the hash being e.g. a SHA-1 of the password's hash
SELECT * FROM ctfnote_private."user" WHERE id = 42 AND encode(digest(password, 'sha1'), 'hex') = '851f5ebcbf8cf861f274b11b0ee1766db91bfd91';
id | login | password | role
----+-------+--------------------------------------------------------------+------------
42 | XeR | $2a$10$XXXXXXXXXXXXXXXXXXXXXXXXXXXX.XXXXXXXXXXXXXXXXXXXXXXXX | user_admin
(1 row)
I propose using SHA-1 because it is faster than MD5.
CRC-32 would be better, but I'm afraid some maniac would try to bruteforce it.
If we agree with my proposal, it means your PR needs the following changes:
- replace password with a "enable ical?" toggle in the admin interface
- replace the password with a boolean in the database
- change the verification logic
Keep in mind that this proposal might make it awkward when we implement #171.
We've been talking about that since 2020 (#20) so "whatever, we'll figure it out later" is a perfectly valid answer.
|
|
||
| watch( | ||
| adminSettings, | ||
| (s) => { | ||
| registrationPassword.value = s.registrationPassword ?? ''; | ||
| registrationPassword.value = s.registrationPassword; |
There was a problem hiding this comment.
Are we sure this NULL-coalescing was not needed ?
| @@ -54,6 +54,7 @@ const ctfRoute: RouteRecordRaw = { | |||
| children: [ | |||
| { | |||
| path: 'task/:taskId(\\d+)-:taskSlug', | |||
| alias: ['task/:taskId(\\d+)'], | |||
There was a problem hiding this comment.
Why do we need this? How is this related to iCal?
|
This is already included in #237 |
This is a successor PR of #146. I modified two things:
Please note that this PR can NOT be merged before #214 is merged because of the order of the migrations.