(:9090 is the backend)

The message at the moment is

There should be a way to put the list of servers in the message.

Make sure that all API endpoints return a message on error cases, and document that in the Api docs.

Right now, all of the dependencies are declared in one of the worst possible ways. It's time to clean that up.

I will probably use koin for this.

Bans should have a timestamp that records when they were created.

And also try and switch to another session recorder that is more robust than the one we are currently using.

There is a lot of setTimeout and other dirty handling of animations in the frontend JavaScript code.
Vue.JS <transition> tag should be able to handle those things much better than they currently are.

The back end tends to, huh, not handle exceptions at all, and Ktor is left to deal with ugly crashes all over the place.

This needs to be improved (probably after the dependency injection refactor pass).

Specifically, all cases where empty-bodied 500 error are replied from the back-end, this needs to be replaced by a more sensible answer that also has proper logging and ApiResponse replies.

A lot of texts or links (for example the privacy policy or the sources URL) are hardcoded on the frontend or simply missing.

To-do

• Add the ToS page and retrieve it from the backend
• Add the privacy policy page and retrieve it from the backend
• Add the about page with instance information retrieved them from the backend
• Retrieve the backend URL from the environment
• Retrieve the identity prompt text from the backend
• Retrieve the sources URL from the backend or the environment Will eventually be replaced by #82

None of the code is documented within bot and that sucks. That needs to be improved.

Frontend still misses minor pages such as the instance information or the about pages.

As GDPR compliance and giving the users the opportunity to control their data is one of the goals of the project, there must be an automated way of letting the user access and delete their data.

• Users must be able to delete their account, provided that they are not banned
  • Solution TBD if they are banned (either deleting their account but remembering that their account is banned)
  • In the end, just allow admins to delete user accounts when they want it.
• Users must be able to access the entire history of accesses done to their true identity
  • It must also be made very clear that they will be notified of every access to their identity. This notification should be done on Discord.
• Users must be able to report an identity access as abusive to the service administrators Just manually ask someone
• Users must be able to access their entire account information in a simple way.

Fully remove the following, which were deprecated in #37

• -u (--unsage-jwt-secret) CLI arguments
• sessionDuration and jwtSecret configuration fields

Endpoints that should be present for admins:

• GET /admin/instance General instance information
• POST /admin/idaccess Get the identity of someone
• POST /admin/ban/new Create a ban
• GET /admin/ban?id=... Get a ban's information (by ban ID, by Discord user ID...)
• POST /admin/ban/revoke Revoke a ban

Looks like crap at the moment

Let's improve that. We already have the utility functions for it, this just needs to be designed and done!

I accidentally encountered this while working on #24 and fixing a bug. An ugly exception is thrown when the user does not accept DMs, or cannot receive it for any reason.

The PR will make that exception a better one, but we still need to find a way to gracefully handle that case.

Not receiving a DM is not a problem, however it is a major issue for receiving identity access notifications. We must make sure that the user receives them at some point.

I was thinking of maybe a check in the database called "notified" (that would be an additional field in the identity acces table), that would be set to false if the notification failed for any reason. If it is false, then we could have some sort of check when the user accepts DMs (or every x time) to try and re-send the message.

Consider being able to edit/add linking steps (e.g. Discord account linking, MS account linking) and/or settings.
This could be done using the configuration or the rules, or even another DST

Currently, frontend is missing both the profile and the ID accesses pages, which must be implemented before the first release.

Testing LinkRoleManager is hell because the three steps are separated:

• Determine which rules are needed
• Determine which roles should be added
• Call the Discord API facade

But are only available under one function, updateRolesOnGuilds which, while handy, is horrible to test because it has so many dependencies that cannot be easily injected and has just too much internal logic.

The three steps are already separated, but the first two steps need to be made public and thoroughly tested.

This was originally done because they were present in config files when they were not needed. They should be removed now, we have ample documentation about all of this.

This issue tracks the general scope of the project, and is expected to be modified as we figure out the details.

Main goals

This category represents the goals that EpiLink MUST fulfill.

Identity verification

• Provide a way to link a Discord and a Microsoft account (possible an Office 365 account, or even a CRI account)
  • Discord OAuth + Microsoft Graph (and its OAuth system)
• Check that the Microsoft account is from an approved domain (e.g. epita.fr)
  • Can be done with a simple Regex, list of domains, etc
• Login-once, validate-everywhere style
  • When a user logs in, authenticate them everywhere

Data control

• Provide an easy way for users to see what data the project has about them.
• Provide a simple way of letting the user delete their account.
  • ...unless they are banned, in which case they will have to contact administrators
• Ensure that no data whatsoever is taken from the user without their consent.
• The user can specify whether or not he wants his identity to be kept in the systems.
  • As in, whether their login is kept or not depends on their choice
  • Users who do end up not disclosing their identity may get restricted services

Strict GDPR compliance

• Go out of our way to respect the GDPR (also comes back to data control)
• Minimum data intake (e.g. hashing data if possible for maximum privacy)

Easy-to-deploy, easy-to-configure

• Use YAML

Reusable

• Do not directly bind to anything EPITA-specific (unless the CRI decides to allow us to do stuff)

May-be-goals

These goals should be fulfilled after the main ones have been done.

• Allow users to select global roles themselves (their promo, their class group...)
  • These would update globally, and the user is still in control of their data
  • Only allow one update every 3 (or more) months to prevent abuse.
  • Some groups are user-defined (promo, class group), some groups are not user selectable (admin, ADM, prof)
  • Users are permabanned if they lie on their promo (ofc we don't permaban genuine mistakes)
  • A log is kept of every user-initiated role update
  • May be updated and determined automatically if the user agrees that EpiLink may keep their identity
  • All groups must be relevant on a global basis. Groups that are only of interest for a single server are out of scope.

Non-goals

• Advanced moderation control (e.g. EpiModo)
• Keeping a record of everyone's identity. EpiLink would be access-control, not binding identities.

The following need to be implemented in the back-end:

• /meta/tos: Returns the Terms of Services as HTML text (e.g. as a <p>). This text is a configuration string or file.
• /meta/privacy: Returns the privacy policy as HTML text. Same as above.
• /meta/info: Needs to return a customizable warning for when someone decides not to keep their identity in the system.

(From #19)

This is because some HTTP endpoints call the role updating functions directly. They need to be launched-and-forgotten, probably with LinkDiscordBot's coroutine scope.

This is especially visible when rules take a while to execute.

Most of the errors case are ignored by the frontend

To-do fixes list

• Handle user refusal during OAuth
• Display error on user-side during backend request instead of just hanging up

(From #19)

• Implement more utility functions from the rulebook. We currently only have httpGetJson
• Implement some sort of "autocast system". Right now, a lot of JSON replies are to be casted with some dirty as? Something ?: error("Unexpected"). This is noisy, maybe something can be done to fix that.

@Litarvan reported some inconsistent slowness on /register endpoints. This needs to be investigated.

Potential clues:

• This might be a temporary slowdown due to lazy objects being initialized for the first time (although that's highly unlikely because MS and Discord backends are initialized with the first call to /meta/info for retrieving the authorization stub)
• This might be a temporary slowdown due to Microsoft or Discord APIs just being slow
• Redis hiccups?
• Ktor client library initialization? The client side of things might not have been used before the first call, and loading it might take a long time.

Needs to be checked:

• Does this happen on only the first call?

Frontend texts are mostly hardcoded in french for now. Translations support must be added before the first release.

Apparently, an empty field in YAML means that it's null, and EpiLink does not like that.

The front-end not being able to talk to the front-end would be a very sad story.

Ktor has native implementation for Cross Origin Resource Sharing

Note that this is only a security lifting technique for web browsers and does not really change anything for server security in general (it just says "Hello browser, you can totally call me from the front-end").

Marking this with bug because this breaks front/back separation.

The footer should be able to contain custom URLs.

• The URLs are defined in the config files on the back-end
• The back-end sends the URLs on the /meta/info endpoint.
• The front-end retrieves the URLs from the /meta/info endpoint and displays them in the footer.

Right now the Discord bot only adds role. It should also remove roles that the user should not have.

This issue will contain news about the project. This will be particularly useful for when the project goes public.

Subscribe to the thread to get notifications! 🎉 💯

The route to edit the privacy settings of the logged user is missing.
The /user route also lacks whether the user is currently sharing its identity or not. --> #75

Specifically, the GET /user endpoint does not indicate whether the user has their identity kept within EpiLink or not.

Same as with #50 but for the database

(aka "how do I run this thing")

In accordance with the "ease-of-use" rule, getting started with the app must be easy. This implies having a solid packaging + deployment methods.

The offered methods for the back end can be:

• "just launch ./gradlew run lol". Worst option, but great for dev. Current one.
• A fat jar (although this might not be feasible as some dependencies are native I think?)
• A distribution (installDist and the likes, offered by Gradle)
• A runtime image (jlink, requires a bit more elbow grease on our side but would be by far the easiest for end-users)

Front-end is still TBD. Also note that multiple packaging options should (and will) be offered.

After that, deployment could be offered through things like Docker or a Snap package, but it's too early to decide on that.

Right now, we only display the exceptions returned by Jackson, which is not the best in terms of clarity.

• Move to cleaner messages for syntax error (invalid YAML)
• Move to cleaner messages for type errors (invalid configuration file, e.g. using an integer instead of a string)
• Add a clean message instead of a raw FileNotFoundException

Implement user endpoints.

• GET /user Get general information on the user
• GET /user/idaccess Get the list of ID accesses
• ...

Currently, user can access some pages he should not be able to, without being redirected.

To-do fixes list

• Redirect from / to the current linking step page
• Redirect from /auth/:service to the current linking step page
• Redirect from /home to /profile when the user is logged

Some elements were originally planned to use JWT, but we have changed our minds on that. The JWT authentication elements need to be removed from the codebase.

Yup.

They're probably better off there.

Although the back-end times out sessions regardless, it would be nice to have a single log-out endpoint like POST /user/logout to delete session information immediately.

The Discord side of EpiLink is just one thick class right now. It needs to be separated and tested.

They're supposed to be at /register/authcode/, not /authcode.

This is the checklist of the data that would be collected through EpiLink. This list must remain openly accessible to anyone accessing the source code, and should eventually be migrated into a doc file in the repository.

This issue can be used as a basis to build Terms of Services, however the EpiLink software project must not provide ToS itself. EpiLink (as a software project) is provided with no warranties whatsoever. The EpiLink Instance run for EPITA will be ran under its own terms of services, which are not to be distributed as part of the software project.

GDPR compliance is only relevant for instances of EpiLink being ran in the EU or instances dealing with European citizens' data. Compliance is not the responsibility of the EpiLink software project, it is the sole responsibility of whoever is running the EpiLink instance.

GDPR compliance and safety MUST be the main concerns of the project in order to maintain user trust.

Moreover, clarity on the collected data is a given, since this project may eventually be open-sourced. There is no point in restricting that.

All TBD items should be changeable through configuration flags.

Collected for: banned users list

• Goal: Maintaining a list of banned users.
• Mandatory: Yes.
• Lawfulness: Necessary for the purposes of the legitimate interests pursued by the controller. A banned user would otherwise be able to evade his ban by simply deleting his account.
• Collected data: Hash of Microsoft account GUID.
• Time scale: TO BE DETERMINED BY INSTANCE MAINTAINER, should be a configuration flag.

This data specifically is non-identifying (because it is a hashed ID), but necessary and cannot be requested to be deleted.

Collected for: general user profile

• Goal: Establishing a basic user profile, confirming the authenticated state, general user data that allows logging into the service.
• Mandatory: Yes for service users.
• Lawfulness: Necessary for the purposes of the legitimate interest pursued by the controller. This is the basic data collected as part of the service.
• Collected data: Hash of Microsoft account GUID, Discord account ID, account creation date, additional account flags specific to the service (e.g. privileged account, certified...)
• Time scale: Until the user deletes their account.

This data can be deleted at any time by deleting the user's account. Additional restrictions on account deletion apply to banned users.

Collected for: identity binding and controlled identity access

• Goal: Knowing which user is who, allowing the service to automatically add relevant roles and securing access even further by knowing exactly who is who
• Mandatory: No. Users who choose that the service may not keep their identity will get restricted service.
• Lawfuless: Depends on what the instance does. If additional services are provided (e.g. automatic role attribution instead of manually doing it), the data subject has given consent for those purposes (a). For accessing restricted resources where security is needed, the processing is necessary for the purposes of the legitimate interests pursued by the controller (f).

Collected for: additional role matching

This data is either collected as part of the identity binding or provided directly by the user. The service must make clear what data is automatically gathered.

(Blocked by #77)

I noticed some mistakes while quickly re-reading some documentation. The docs files need to be proofread and updated with the latest information prior to the v0.1 release.

Blocked by #77 because that PR introduces fairly important docs changes.

While textual logs are nice, most privileged actions require logging some sort of sensitive data. As such, we should consider adding a proper audit log, stored in the database, with important events.

Examples of actions that could be stored:

• Account creation ACC_CREATE
• Account logged in ACC_LOGIN

This audit log must never be accessible to users. This is a strictly administrative log intended for recovering from catastrophic events.

The deletion of an account from EpiLink should also delete (or rather censor) relevant elements within the database after a delay (like 30 days).

In the mean time, if advanced logging is required, users should set epilink's logging to DEBUG and roll with that to get spammed with stuff.

Currently the backend is logging nothing but the startup phase (except from the dependencies logs).

To my mind, should be logged at least the registration of a user (even if there is no private information), the update of a role, etc.
In debug, this should definetely be more precise, because currently when the backend fails, the only way to find out where it comes from is by debugging.