-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add iCal link #146
Add iCal link #146
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks fine to me. Some small things only have to be changed in order to merge this.
About the other PRs:
- Fix the table view to wrap lines instead of overflowing the window border.
Is this related to / based on #111? And is it similar?
- Add a "last active date" to the admin backend for each user
I like the addition. Could be useful when cleanup the database.
- Add authentication with hedgedoc so that /pad/ isn't publicly-writeable (and writeups are secret by default)
I think this was based on my code of CTFNote 1.0? We had a discussion in #68 about this and because it was quite a hacky solution, it was decided to not add this. Also, Hedgedoc 2.0 is coming up and that would definitely break this integration so I don't think that it will be merged for now...
- Add better password requirements by integrating with the haveibeenpwned API.
Sure, why not? If you already have the code and it works, I would be happy to merge it!
Thank you for the review. Changes should be added later today, but it might also take a few days because I'm away for the weekend.
Yes, I think it's pretty much the same thing, no need to merge.
I agree that it's a hacky solution. Hedgedoc 2 should fix it but we didn't want to wait. I will open the other two PRs next week :) |
* Fix eslint errors * Fix insecure randomness in Registration.vue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution!
@XeR, can you review this too and merge this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work on this feature. Sorry for the slow response time.
On top of the comments regarding your changes, I noticed you changed the destination URL.
On @B-i-t-K's branch, the iCal URL points to the CTF platform, while on yours it points to CTFNote.
I have mixed feelings about this. I'd like to have users' input.
My personal use case is to have icalendars synchronized with a smartphone.
I never connect to CTFNote from a smartphone.
I would rather have the link point to the CTF platform so that I can see how my team is doing on the scoreboard.
I used to import ics files from CTFtime to a Nextcloud instance.
What are your use cases ? Do you synchronise this with a software calendar on a computer (Thunderbird, Apple Calendar, Microsoft Whatever, etc.) ?
api/src/routes/ical.ts
Outdated
for (const ctf of ctfs) { | ||
// Assumes that CTFNote is hosted at the root of the domain | ||
const ctf_url = new URL( | ||
`/#/ctf/${ctf.id}-${slugify(ctf.title)}/info`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment about the slugify
package.
Can we retrieve ctf.slug
instead ? See /front/src/components/Utils/CtfNoteLink.vue
, line 29.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we do not use this package
CTFNote/front/src/ctfnote/ctfs.ts
Lines 47 to 49 in c125a07
function safeSlugify(str: string) { | |
return slugify(str) || 'no-slug-for-you'; | |
} |
The ctf.slug
is generated in the frontend when creating a Ctf
from a CtfFragment
, so it's not available to the API:
CTFNote/front/src/ctfnote/ctfs.ts
Lines 89 to 91 in c125a07
export function buildCtf(ctf: CtfFragment): Ctf { | |
const slug = safeSlugify(ctf.title); | |
const params = { ctfId: ctf.id, ctfSlug: slug }; |
I don't really see why the API shouldn't just generate the slug itself, using the same function as the frontend. Especially because the slug doesn't matter, it's purely visual (as long as the id is correct, the CTF will show).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is perfectly to regenerate it in the backend since it is nice to see which CTF you are going to visit when clicking the link. Do you agree @XeR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So how should I approach / fix / resolve this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can leave it like this or if it is purely visual then you may also remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@frereit, can you confirm that the slugify in the backend is purely visual? So that means that if we remove the slugify part from the URL, the link still works? If so, I think it is preferred to remove the dependency and therefore the slugified part of the URL. So we only show a URL with an ID in it. I don't think this is a problem since the event will already contain the name of the event.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the slug is purely visual, however just the id is not enough, so a valid URL for CTF with id 20 needs to match/\/#\/ctf\/20-.+\//
. Just /#/ctf/20/
wouldn't work. I haven't looked into this, but should be trivial to change the logic to allow id-only links. If you want, I can do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that is the best solution. If you could change it to accept only IDs, that would be very nice!
Yes, I synchronise this with Outlook. Regarding the problem with determining the URL of the CTF on CTFNote reliably, I think it might be best to point to the CTF itself. I could always add an |
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
@@ -54,6 +55,7 @@ const ctfRoute: RouteRecordRaw = { | |||
children: [ | |||
{ | |||
path: 'task/:taskId(\\d+)-:taskSlug', | |||
alias: ['task/:taskId(\\d+)'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I am visiting a URL like http://localhost:8088/#/ctf/1/info
and then click on the tasks tab, then I get an empty screen and the following warning in the console:
The URL that has the empty page is http://localhost:8088/#/ctf/1-Midnight-Sun-CTF-2022-Quals/tasks
in my case. So this is probably due to the slug being added again to the URL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, interesting bug. I don't think the warning has anything to do with the bug, though (at least I can't reproduce the warning on my side).
Interestingly when just refreshing website at the same URL it works as expected. I am investigating, but no clue what's causing this yet. Adding an alias for a URL shouldn't break things this way imo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok so I can't find an easy fix for this right now. Unfortunately I will be pretty busy again this week and might only get to this next week, sorry.
This work is mostly by @B-i-t-K from PR #116 but I finished it by adding a /calendar.ics route in the nginx proxy and slightly updating the frontend.
I added back graphql.schema.json because it should be deleted in a seperate PR / merge or directly on dev to avoid doing multiple things on one branch.
Yes. This is done now, and the pool uses the postgraphile "user" instead of "admin"
Edit:
And while this PR is open: We also made some more changes to CTFNote:
If you want any of these changes upstream just let me know and I can open a PR for any one of those.