This makes it more convenient to modify the permission model, both for
future modifications and for custom installations.
This changes the `owner` property of NoteSession to `ownerId`, which is
a more accurate description anyway.
Signed-off-by: Dexter Chua <dec41@srcf.net>
OAuth2 allows the user to only consent to a subset of the scopes
requested. Previously, the Generic Oauth2 implementation assumes that
the `username`, `email` and `displayName` attributes are supplied, and
may crash if they are not defined.
This commit allows for `email` and `displayName` to not be defined,
either through the user refusing consent or the OAuth2 configuration
not asking for them in the first place (by not setting
`userProfile*Attr`).
If `email` is not provided, the `emails` property is simply left empty.
If `displayName` is not provided, it is left undefined, and CodiMD uses
the `username` whenever the `displayName` is expected.
This does not deal with the case where `username` is not provided. Since
usernames are not unique in CodiMD, it is possible to deal with this by
setting a dummy username. This can be added in a future commit if
desired.
Fixes#406
Signed-off-by: Dexter Chua <dalcde@yahoo.com.hk>
This allows configuring the group and mode of the unix socket after it
has been created to allow reverse proxies to access it. Fixes#317.
I decided to call `chown` and `chgrp` directly to change the owner and
group (the former will almost definitely not be called; only root can
chown a file to another user, and you are not running codimd as root. It
is included for consistency).
The nodejs chown/chgrp functions only accepts uid and gid, not the names
of the user or group. The standard way to convert a group name into a gid
is the `uid-number` package. The way this package works is that
1. It spawns a new nodejs process
2. The new nodejs process calls nodejs' setgid function, which *does*
accept both the group name and gid
3. It then calls getuid to retrieve the uid of the process, and returns
it to the parent process via stdout.
While this *works*, it is hacky, and if we are spawning a process
anyway, might as well call `chgrp` directly.
This does not update the documentation because we are merging into
release/2.0.x but master reworks the configuration section of the
documentation, so there will be a conflict when we merge anyway.
Signed-off-by: Dexter Chua <dalcde@yahoo.com.hk>
The code intends to check if the note is anonymous by checking if it has
an owner. If it is anonymous, the default permission must be `freely`.
However, at this point in the code, `owner` is never populated; only
`ownerId` is. The property `owner` is automatically filled in *after*
the Note is created, but this call happens before that.
Thus, the default note permission is always `freely`, regardless of the
`defaultPermission` setting. By checking `ownerId` instead of `owner`,
the anonymity and hence default permission is correctly determined,
This is especially an issue when `allowAnonymous` is `false`, since this
would allow the user to create a note with `freely` permission when it
should not be allowed.
Signed-off-by: Dexter Chua <dalcde@yahoo.com.hk>
The OAuth2 specification RECOMMENDS setting the state to protect against
CSRF attacks. Some OAuth2 providers (e.g. ORY Hydra) refuse to
authenticate without the state set.
Signed-off-by: Dexter Chua <dalcde@yahoo.com.hk>
The previous Profile type was renamed to PassportProfile, as it is only used for profile-information from Passport plugins.
All functions relating to profile-parsing are now encapsulated in the PhotoProfile class (naming still debatable).
Signed-off-by: David Mehren <dmehren1@gmail.com>
It turns out our shiny new typed ES2015 `Map`s are not serializable to JSON. :(
Luckily, we only use strings as keys and can write a function that converts them to serializable objects!
Signed-off-by: David Mehren <dmehren1@gmail.com>
a7aaded6 started to use a Map for a users note history in various places, but didn't update the code to actually use the Map operations. This broke updating the note history.
Signed-off-by: David Mehren <dmehren1@gmail.com>
`mock-require` does not work with TypeScript, as the compiled JS expects a sub-object: `import { config } from Config` compiles to `const config_1 = require("./config")`, but the config object is now in `config_1.config`, *not* in `config_1` directly.
Therefore `mock-require` was replaced with `ts-mock-imports`, which also simplifies the code a bit.
Signed-off-by: David Mehren <dmehren1@gmail.com>
