Before, closed disallowed guest edits completely, by removing
the `freely` permission. This makes it possible to explicitely bring
back guest-editing, but not guest-note-creation, to closed instances.
Signed-off-by: Dario Ernst <dario@kanojo.de>
[CodeTriage](https://www.codetriage.com/) is an app I have maintained
for the past 4-5 years with the goal of getting people involved in
Open Source projects like this one. The app sends subscribers a random
open issue for them to help "triage". For some languages you can also
suggested areas to add documentation.
The initial approach was inspired by seeing the work of the small
core team spending countless hours asking "what version was
this in" and "can you give us an example app". The idea is to
outsource these small interactions to a huge team of volunteers
and let the core team focus on their work.
I want to add a badge to the README of this project. The idea is to
provide an easy link for people to get started contributing to this
project. A badge indicates the number of people currently subscribed
to help the repo. The color is based off of open issues in the project.
Here are some examples of other projects that have a badge in their
README:
- https://github.com/crystal-lang/crystal
- https://github.com/rails/rails
- https://github.com/codetriage/codetriage
Thanks for building open source software, I would love to help you find some helpers.
This determines which ldap field is used as the username on
HackMD. By default, the "id" is used as username, too. The id
is taken from the fields `uidNumber`, `uid` or
`sAMAccountName`. To give the user more flexibility, they can
now choose the field used for the username instead.
Documentation added in aaf034b on Nov 17th 2016 says the S3 bucket can
be specified with `s3.bucket`, but commit c8bcc4c (#285) on Dec 18th
2016 used `s3bucket`. Instead of fixing the code (#552) to match the
documentation this commit changes just the documentation so that
existing configurations are not broken. Also, the `s3` object is passed
as is to `AWS.S3()`, which does not know the option `bucket` (but
silently ignores it in my test).
http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#constructor-property
Following the old documentation leads to this exception:
2017-09-23T09:42:38.079Z - error: MissingRequiredParameter: Missing required key 'Bucket' in params
at ParamValidator.fail (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/param_validator.js:50:37)
at ParamValidator.validateStructure (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/param_validator.js:61:14)
at ParamValidator.validateMember (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/param_validator.js:88:21)
at ParamValidator.validate (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/param_validator.js:34:10)
at Request.VALIDATE_PARAMETERS (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/event_listeners.js:125:42)
at Request.callListeners (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
at callNextListener (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/sequential_executor.js:95:12)
at /srv/hackmd/hackmd/node_modules/aws-sdk/lib/event_listeners.js:85:9
at finish (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/config.js:315:7)
at /srv/hackmd/hackmd/node_modules/aws-sdk/lib/config.js:333:9
at Credentials.get (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/credentials.js:126:7)
at getAsyncCredentials (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/config.js:327:24)
at Config.getCredentials (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/config.js:347:9)
at Request.VALIDATE_CREDENTIALS (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/event_listeners.js:80:26)
at Request.callListeners (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/sequential_executor.js:101:18)
at Request.emit (/srv/hackmd/hackmd/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
Limitations as of this commit:
- tlsOptions can only be specified in config.json, not as env vars
- authentication failures are not yet gracefully handled by the UI
- instead the error message is shown on a blank page (/auth/ldap)
- no email address is associated with the LDAP user's account
- no picture/profile URL is associated with the LDAP user's account
- we might have to generate our own access + refresh tokens,
because we aren't using oauth. The currently generated
tokens are just a placeholder.
- 'LDAP Sign in' needs to be translated to each locale