Code Monkey home page Code Monkey logo

konnect's Introduction

Konnect

Kopano Konnect implements an OpenID provider (OP) with integrated web login and consent forms.

Go Report Card

Technologies

  • Go
  • React

Quickstart

Either download a Konnect binary release from https://download.kopano.io/community/konnect:/ or use the Docker image from https://hub.docker.com/r/kopano/konnectd/ to run Konnect. For details how to run Konnect see below.

Standards supported by Konnect

Konnect provides services based on open standards. To get you an idea what Konnect can do and how you could use it, this section lists the OpenID Connect standards which are implemented.

Furthermore the following extensions/base specifications extend, define and combine the implementation details.

Build dependencies

Make sure you have Go 1.13 or later installed. This project uses Go Modules.

Konnect also includes a modern web app which requires a couple of additional build dependencies which are furthermore also assumed to be in your $PATH.

To build Konnect, a Makefile is provided, which requires make.

When building, third party dependencies will tried to be fetched from the Internet if not there already.

Building from source

git clone <THIS-PROJECT> konnect
cd konnect
make

Optional build dependencies

Some optional build dependencies are required for linting and continuous integration. Those tools are mostly used by make to perform various tasks and are expected to be found in your $PATH.

Build with Docker

docker build -t konnectd-builder -f Dockerfile.build .
docker run -it --rm -u $(id -u):$(id -g) -v $(pwd):/build konnectd-builder

Running Konnect

Konnect can provide user login with Kopano Groupware Storage server as backend, use a cookie aware web login area which supports the ?continue parameter, or also can directly connect to a LDAP server.

All backends require certain general parameters to be present. Create a RSA key-pair file with openssl genpkey -algorithm RSA -out private-key.pem -pkeyopt rsa_keygen_bits:4096 and provide the key file with the --signing-private-key parameter. Konnect can load PEM encoded PKCS#1 and PKCS#8 key files and JSON Web Keys from .json files If you skip this, Konnect will create a random non-persistent RSA key on startup.

To encrypt certain values, Konnect needs a secure encryption key. Create a suitable key of 32 bytes with openssl rand -out encryption.key 32 and provide the full path to that file via the --encryption-secret parameter. If you skip this, Konnect will generate a random key on startup.

To run a functional OpenID Connect provider, an issuer identifier is required. The iss is a full qualified https:// URI pointing to the web server which serves the requests to Konnect (example: https://example.com). Provide the Issuer Identifier with the --iss parametter when starting Konnect.

Furthermore to allow clients to utilize the Konnect services, clients need to be known/registered. For now Konnect uses a static configuration file which allows clients and their allowed urls to be registered. See the the example at identifier-registration.yaml.in. Copy and modify that file to include all the clients which should be able to use OpenID Connect and/or OAuth2 and start Konnect with the --identifier-registration-conf parameter pointing to that file. Without any explicitly registered clients, Konnect will only accept clients which redirect to an URI which starts with the value provided with the --iss parameter.

Konnect cryptography and validation

A tool can be used to create keys for Konnect and also to validate tokens to ensure correct operation is Step CLI. This helps since OpenSSL is not able to create or validate all of the different key formats, ciphers and curves which are supported by Konnect.

Here are some examples relevant for Konnect.

step crypto keypair 1-rsa.pub 1-rsa.pem \
  --kty RSA --size 4096 --no-password --insecure
step crypto keypair 1-ecdsa-p-256.pub 1-ecdsa-p-256.pem \
  --kty EC --curve P-256 --no-password --insecure
step crypto jwk create 1-eddsa-ed25519.pub.json 1-eddsa-ed25519.key.json \
  -kty OKP --crv Ed25519 --no-password --insecure
echo $TOKEN_VALUE | step crypto jwt verify --iss $ISS \
  --aud playground-trusted.js --jwks $ISS/konnect/v1/jwks.json

URL endpoints

Take a look at Caddyfile.example on the URL endpoints provided by Konnect and how to expose them through a TLS proxy.

The base URL of the frontend proxy is what will become the value of the --iss parameter when starting up Konnect. OIDC requires the Issuer Identifier to be secure (https:// required).

Kopano Groupware Storage server backend

This assumes that Konnect can connect directly to a Kopano server via SOAP either using a unix socket or a TCP connection.

Kopano Groupware Storage server backend connections can either use a dedicated service connection which might require a TLS certificate or a certain unix user to access the unix socket (not recommended) or bind the Konnect session and tokens to the underlaying Groupware Storage server's session (default).

export KOPANO_SERVER_DEFAULT_URI=http://mykopano.local:236

bin/konnectd serve --listen=127.0.0.1:8777 \
  --iss=https://mykonnect.local \
  kc

Give dedicated user session credentials via environment variables as shown in the example below.

export KOPANO_SERVER_DEFAULT_URI=http://mykopano.local:236
export KOPANO_SERVER_USERNAME=my-kopano-user
export KOPANO_SERVER_PASSWORD=my-kopano-password

bin/konnectd serve --listen=127.0.0.1:8777 \
  --iss=https://mykonnect.local \
  kc

Or run Konnect as local_admin_unix user. Only run konnectd like this when you actually use that authentication scheme. Otherwise ensure that Konnect is not running as local admin user for best security.

su - kopano
export KOPANO_SERVER_DEFAULT_URI=file:///run/kopano/server.sock
export KOPANO_SERVER_USERNAME=SYSTEM

bin/konnectd serve --listen=127.0.0.1:8777 \
  --iss=https://mykonnect.local \
  kc

In some situations the only option is to authenticate to the backend by providing TLS client certificate and private key via environment variables.

export KOPANO_SERVER_DEFAULT_URI=https://mykopano.local:237
export KOPANO_SERVER_USERNAME=SYSTEM
export KOPANO_CLIENT_CERTIFICATE=/path/to/client-tls/client-0.pem
export KOPANO_CLIENT_PRIVATE_KEY=/path/to/client-tls/client-0.key

bin/konnectd serve --listen=127.0.0.1:8777 \
  --iss=https://mykonnect.local \
  kc

LDAP backend

This assumes that Konnect can directly connect to an LDAP server via TCP.

export LDAP_URI=ldap://myldap.local:389
export LDAP_BINDDN="cn=admin,dc=example,dc=local"
export LDAP_BINDPW="its-a-secret"
export LDAP_BASEDN="dc=example,dc=local"
export LDAP_SCOPE=sub
export LDAP_LOGIN_ATTRIBUTE=uid
export LDAP_EMAIL_ATTRIBUTE=mail
export LDAP_NAME_ATTRIBUTE=cn
export LDAP_UUID_ATTRIBUTE=uidNumber
export LDAP_UUID_ATTRIBUTE_TYPE=text
export LDAP_FILTER="(objectClass=organizationalPerson)"

bin/konnectd serve --listen=127.0.0.1:8777 \
  --iss=https://mykonnect.local \
  ldap

Cookie backend

A cookie backend is also there for testing. It has limited amount of features and should not be used in production. Essentially this backend assumes a login area uses a HTTP cookie for authentication and Konnect is runnig in the same scope as this cookie so the Konnect request can read and validate the cookie using an internal proxy request.

This assumes that you have a set-up Kopano with a reverse proxy on https://mykopano.local together with the proper proxy configuration to pass through all requests to the /konnect/v1/ prefix to 127.0.0.1:8777. Kopano Webapp supports the ?continue= request parameter and the domains of possible OIDC clients need to be added into webapp/config.php with the REDIRECT_ALLOWED_DOMAINS setting.

bin/konnectd serve --listen=127.0.0.1:8777 \
  --iss=https://mykopano.local \
  --sign-in-uri=https://mykopano.local/webapp/ \
  cookie https://mykopano.local/webapp/?load=custom&name=oidcuser "KOPANO_WEBAPP encryption-store-key"

Run with Docker

Kopano Konnect supports Docker to easily be run inside a container. Running with Docker supports all features of Kopano Konnect and can make use of Docker Secrets to manage sensitive data like keys.

Kopano provides official Docker images for Konnect.

docker pull kopano/konnectd

Run Konnect with Docker Swarm

Setup the Docker container in swarm mode like this:

cat /etc/kopano/konnectd-tokens-signing-key.pem | docker secret create konnectd_signing_private_key -
openssl rand 32 | docker secret create konnectd_encryption_secret -
docker service create \
	--read-only \
	--user=$(id -u kopano) \
	--group=$(id -g kopano) \
	--mount type=bind,source=/etc/ssl/certs,target=/etc/ssl/certs,readonly \
	--secret konnectd_signing_private_key \
	--secret konnectd_encryption_secret \
	--env KOPANO_SERVER_DEFAULT_URI=file:///run/kopano/server.sock \
	--mount type=bind,source=/run/kopano,target=/run/kopano \
	--publish published=8777,target=8777,mode=host \
	--name=konnectd \
	kopano/konnectd \
	serve \
	--iss=https://mykonnect.local \
	kc

This example assumes the local system has a user kopano which can access the Kopano Groupware Core unix socket as admin user SYSTEM.

Run Konnect from Docker image

openssl rand 32 -out /etc/kopano/konnectd-encryption-secret.key
docker run --rm=true --name=konnectd \
	--read-only \
	--user=$(id -u kopano):$(id -g kopano) \
	--volume /etc/ssl/certs:/etc/ssl/certs:ro \
	--volume /etc/kopano/konnectd-tokens-signing-key.pem:/run/secrets/konnectd_signing_private_key:ro \
	--volume /etc/kopano/konnectd-encryption.key:/run/secrets/konnectd_encryption_secret:ro \
	--env KOPANO_SERVER_DEFAULT_URI=file:///run/kopano/server.sock \
	--volume /run/kopano:/run/kopano:rw \
	--publish 127.0.0.1:8777:8777 \
	kopano/konnectd \
	serve \
	--iss=https://mykonnect.local \
	kc

Of course modify the paths and ports according to your requirements. The Docker examples are for the kc identity manager, but work for the others as well if you adapt the parameters and environment variables. The above example assumes the local system has a user kopano which can access the Kopano Groupware Core unix socket as admin user SYSTEM.

Build Konnect Docker image

This project includes a Dockerfile which can be used to build a Docker container from the locally build version. Similarly the Dockerfile.release builds the Docker image locally from the latest release download.

docker build -t kopano/konnectd .
docker build -f Dockerfile.release -t kopano/konnectd .

Run unit tests

cd ~/go/src/stash.kopano.io/kc/konnect
make test

Development

As Konnect includes a web application (identifier), a Caddyfile.dev file is provided which exposes the identifier's web application directly via a webpack dev server.

Debugging

Konnect is built stripped and without debug symbols by default. To build for debugging, compile with additional environment variables which override/reset build optimization like this

LDFLAGS="" GCFLAGS="all=-N -l" ASMFLAGS="" make cmd/konnectd

The resulting binary is not stripped and sutiable to be debugged with Delve.

To connect Delve to a running Konnect binary you can use the make dlv command. Control its behavior via DLV_* environment variables. See the Makefile source for details.

DLV_ARGS= make dlv

Remote debugging

To use remote debugging, pass additional args like this.

DLV_ARGS=--listen=:2345 make dlv

IDE integration for development and debugging

Some editors like VSCode are offering integrated debugger support for Go based software via extensions. Konnect can be started directly from such an IDE by pointing the IDE to the corresponding cmd which should be debugged. This is most likely cmd/konnect.

Example .vscode/launch.json for building and running konnectd directly from VSCode:

{
	"version": "0.2.0",
	"configurations": [
		{
			"name": "Run Konnect kc",
			"type": "go",
			"request": "launch",
			"mode": "debug",
			"program": "${workspaceFolder}/cmd/konnectd",
			"args": [
				"serve",
				"--listen=0.0.0.0:8777",
				"--iss=https://your-issuer:8443",
				"--log-level=debug",
				"--identifier-client-path=${workspaceFolder}/identifier/build",
				"--identifier-registration-conf=${workspaceFolder}/identifier-registration.yaml",
				"--identifier-scopes-conf=${workspaceFolder}/scopes.yaml",
				"--signing-method=ES256",
				"--signing-private-key=${workspaceFolder}/examples/keys/example-1-ecdsa-p-256.pem",
				"--encryption-secret=${workspaceFolder}/examples/encryption.key",
				"--validation-keys-path=${workspaceFolder}/examples/keys",
				"--allow-dynamic-client-registration",
				"--allow-client-guests",
				"kc",
			],
			"env": {
				"KOPANO_SERVER_DEFAULT_URI": "http://127.0.0.1:236",
			},
		},
		{
			"name": "Attach",
			"type": "go",
			"request": "launch",
			"remotePath": "${workspaceFolder}/.gopath/src/stash.kopano.io/kc/konnect",
			"mode": "remote",
			"port": 2345,
			"host": "127.0.0.1",
			"program": "${workspaceFolder}",
		},
	]
}

The Run konnect kc launcher builds and runs konnectd with the debugger attached to it directly, while the Attach launcher connects to a remote debugger.

See https://github.com/go-delve/delve/blob/master/Documentation/EditorIntegration.md for further examples and details.

Usage survey

By default, any running konnectd regularly transmits survey data to a Kopano user survey service at https://stats.kopano.io . To disable participation, set the environment variable KOPANO_SURVEYCLIENT_AUTOSURVEY to no.

The survey data includes system and platform information and the following specific settings:

  • Identify manager name (as selected when starting konnectd)

See here for further documentation and customization possibilities.

License

See LICENSE.txt for licensing information of this project.

konnect's People

Contributors

deepdiver1975 avatar dependabot[bot] avatar fbartels avatar iljan avatar klausade avatar longsleep avatar snehal1112 avatar sotneo avatar trickvi avatar weblate avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

konnect's Issues

`--log-level` not available for `cookie` ?

In whatever order I try to start konnectd (via docker) it always fails to start with the error message:
Error: unknown flag: --log-level.

kopano/konnectd:0.9.0 --identifier-client-path ./identifier-univention --iss=https://ucs-sso.school.dev --sign-in-uri=https://ucs-sso.school.dev/fbest/ --log-level debug serve cookie 'https://ucs-sso.school.dev/fbest/?load=custom'

kopano/konnectd:0.9.0 --identifier-client-path ./identifier-univention --iss=https://ucs-sso.school.dev --sign-in-uri=https://ucs-sso.school.dev/fbest/ serve --log-level debug cookie 'https://ucs-sso.school.dev/fbest/?load=custom'

kopano/konnectd:0.9.0 --identifier-client-path ./identifier-univention --iss=https://ucs-sso.school.dev --sign-in-uri=https://ucs-sso.school.dev/fbest/ serve cookie --log-level debug 'https://ucs-sso.school.dev/fbest/?load=custom'

kopano/konnectd:0.9.0 --identifier-client-path ./identifier-univention --iss=https://ucs-sso.school.dev --sign-in-uri=https://ucs-sso.school.dev/fbest/ serve cookie 'https://ucs-sso.school.dev/fbest/?load=custom' --log-level debug

Is --log-level not available when using the cookie backend?

When starting the docker container regulary with ldap plugin it seems to be working:

/var/lib/konnectd-docker # ps aufx
PID   USER     TIME  COMMAND
    1 nobody    0:01 konnectd serve --identifier-registration-conf /etc/kopano/identifier-registration.yaml --identifier-client-path ./identifier-univention --log-level debug ldap --iss=https://ucs-sso.school.dev

Further improve usage as library

As #19 is merged we would like to propose some follow up changes to further improve embedding.

Configuration files/keys

Instead of storing the path to the file the bootstrap should contain the unmarshaled config struct. With this change the consumer can decide how the load/un-marshall the config during the boot-process (etcd, hard-coded, different format). This would also decouple the business-logic from any io which should also improve test-ability.

This will require some concept on how to add extension-points to the bootstrap. (Extend interface introduced in #19 ?)

Assets (index.html)

Similar as above but here the path to index.html would be replaced by an io.reader of to allow loading assets from an vfs or do some other processing. Identifier-webapp should be optional as it might be hosted on another server.

SAML Allow for issuer != MetadataEndpoint

If used with keycloak as authority, keycloak uses an issuer URI that is different from it's metadata URI. It would be preferable to use a config field in the registration.yaml to account for that.

[Spec] Graph Backend

Graph Backend

With this backend users can be authenticated against the GraphAPI. (grapi or owncloud ocis graph).
lorem ...

Login Endpoint

The Graph API requires an login endpoint which allows konnect to verify the users credentials

curl -X POST -H 'Content-Type: application/json' -d '{"username":"alice","password":"something"}' -u id:secret http://domain.tld/graph/v1.0/login

A shared id and secret is used to authenticate the request itself.

The response is a json encoded object holding at least the id. The id is later used to query the additional user information from the /users endpoint

Query User Endpoint

curl -X POST -H 'Content-Type: application/json' -d '{"username":"alice","password":"something"}' -u id:secret http://domain.tld/graph/v1.0/users/${id}

A shared id and secret is used to authenticate the request itself.

The response is a json encoded object holding all known information within the graph.

Resolve User Endpoint

TODO: find the correct query in the graph api ;-)

Add eye icon for password field

Useful on mobile devices but also on desktop to check if the entered password is actually correct.

Add an eye icon at the end of the password field to show/hide the password.

Access tokens use algo 'PS256' which seems not to be supported/implemented by any token verifier ....

The token returned by konnectd looks like this:
screenshot from 2018-10-16 09-27-29

I tried to verify the token using various verification libraries and non of them understands PS256.
Is there a config option to change this?

Error for Okta: The algorithm "PS256" is not supported or does not implement SignatureInterface.

		$jwtVerifier = (new \Okta\JwtVerifier\JwtVerifierBuilder())
			->setDiscovery(new \Okta\JwtVerifier\Discovery\Oidc())
			->setAdaptor(new \Okta\JwtVerifier\Adaptors\SpomkyLabsJose())
//			->setAudience('api://default')
			->setClientId('ownCloud')
			->setIssuer('https://mykonnect.local:8443')
			->build();

		$jwt = $jwtVerifier->verify($bearerToken);

THX

Embedding Konnectd as dependency?

We are currently working on wrapping konnectd within a go-micro service. The idea is to add konnect as a dependency then initialize the server from go-micro.

Problem is that there is a fairly large amount of private bootstrap code. To my understanding, the parsing of cli-flags and configs is tightly coupled to the initialization of konnectd.

To solve this a large config struct with all config-parameters could be created to decouple the config from the cli-library and environment. The bootstrap code should receive this struct and validate and parse it to create managers, and construct other required parts of the server.

This is just an idea. Happy to discuss and provide a PR :)

subject is based on the ldap dn, which is neither stable, nor non-reassignable

AFAICT the OIDC subject claim is based on the distinguished name of an ldap user. But distinguished names are subject to change when

  • the rdn, eg. cn or uid changes because of marriage, divorce or the ldap admin deciding to move from U123456 style cns to firstname.lastname style (yep we had that)
  • the user moves to a different group
  • a rename happens, eg. to prevent collisions when merging user trees (eg. due to company merger)

BTW: uid, cn or samaccountname are not unique because they may collide in a multi domain environment. And they are subject to change.

The next best thing is the LDAP server specific uuid attribute (openldap has entryuuid, active directory has objectguid, more exist) which is randomly generated when an ldap node is created.

Unfortunately, a savvy admin might decide to copy a user to a different node, eg. to perform batch renames. In that case a new uuid is generated. Which is why AD recommends using the objectSID (security identifiers) over the objectguid. While it will change, even when the user is moved (not copied) around, old objectSID entries are kept in the sIDHistory attribute of the user, see the ms docs for details.

The NTFS filesystem stores permissions based on the sid of a user, because even when it changes the user can still be looked up by matching the sid against the objectsid AND the sid-history attribute.

ownCloud tries to find a user dn based on whatever login attribute was configured. It keeps track of the users dn, the uuid and a generated internal ownCloud username for that user. The code allows changes of the dn because it will fallback to a uuid based search and update the dn in the mapping table if it changed. We currently recommend to use the uuid attribute as the internal username because we wrongly assumed it would be stable ... until we ran into that admin that copied all users. Actually, the internal username will never be updated to prevent data loss, but now the uuid in ldap and the owncloud username no longer match, which is confusing and makes debugging unnecessary hard.

That being said, what can be done, when you are facing the same problem?
For AD you can store and lookup the users subject claim based on the objectsid / sid-history values.
Unfortunately, openldap does not have something like a enryuuidhistory attribute (or I am not aware of it), otherwise you could identify the user based on the sIDHistory. The onlyIdea I have is documenting a recommendation to let the admin generate a real stable non-reassignable uuid attribute. ๐Ÿคทโ€โ™‚๏ธ

Maybe the SCIM rfcs define a schema and attribute for the SCIM id that can be added to an openldap ad, but I havent found it.

Maybe it makes more sense to separate the problem and implement a SCIM backend. Then the actual scim id to ldap user mapping is the problem of another service. Ad if you already have a SCIM in place yo can use that (see http://www.simplecloud.info/#Implementations2 for a list of implementations)

Opinions?

Commit f8c1f4a (current top) does not build

I have just tested my build script on Arch Linux again for konnect, which pulls master from here.
The current top commit f8c1f4a fails with the following error during make:

cmd/konnectd/bootstrap_ldap.go:65:20: undefined: "stash.kopano.io/kc/konnect/vendor/stash.kopano.io/kc/konnect/identifier/backends/ldap".AttributeNumericUID
cmd/konnectd/bootstrap_ldap.go:73:81: too many arguments in call to backends.NewLDAPIdentifierBackend
        have (*config.Config, *tls.Config, string, string, string, string, string, string, []string, map[string]string)
        want (*config.Config, *tls.Config, string, string, string, string, string, string, map[string]string)
make: *** [Makefile:41: cmd/konnectd] Fehler 2
==> ERROR: An Error happened in build().
    aborting...

With no changes to my build script, the last working commit I tested with is d974b04 which was before the LDAP related changes referenced in issue #3 in this repo.
Let me know if you need any more details, please.

SIGSEGV on startup due to uri parse error in identifer-registration.yaml

Konnectd will crash on startup when parsing an invalid redirect uri exists in identifier-registration.yaml:

time="2019-06-12T15:45:25Z" level=debug msg="parsing identifier registration conf from /etc/kopano/identifier-registration.yaml"
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x843381]

goroutine 1 [running]:
stash.kopano.io/kc/konnect/identity/clients.(*Registry).Register(0xc00007c6e0, 0xc000094dc0, 0x0, 0x0)
        /var/lib/jenkins/jobs/kc_konnect/branches/master/workspace/.gopath/src/stash.kopano.io/kc/konnect/identity/clients/registry.go:118 +0x5d1
stash.kopano.io/kc/konnect/identity/clients.NewRegistry(0xb633e0, 0xc00002a058, 0xc0000d2500, 0x7fffbf14636a, 0x28, 0xb6f460, 0xc00005e960, 0x0, 0xc00010bb50, 0x40b689)
        /var/lib/jenkins/jobs/kc_konnect/branches/master/workspace/.gopath/src/stash.kopano.io/kc/konnect/identity/clients/registry.go:74 +0x146
main.newManagers(0xb633e0, 0xc00002a058, 0xc000090a00, 0xc0000e8ff0, 0xc00010bba0, 0x68)
        src/stash.kopano.io/kc/konnect/cmd/konnectd/managers.go:55 +0x2d3
main.(*bootstrap).setup(0xc000090a00, 0xb633e0, 0xc00002a058, 0x1, 0xc00005e960)
        src/stash.kopano.io/kc/konnect/cmd/konnectd/bootstrap.go:322 +0x5a
main.serve(0xc00008f900, 0xc0000d2300, 0x1, 0x8, 0x4, 0xa7c182)
        src/stash.kopano.io/kc/konnect/cmd/konnectd/serve.go:102 +0x332
main.commandServe.func1(0xc00008f900, 0xc0000d2300, 0x1, 0x8)
        src/stash.kopano.io/kc/konnect/cmd/konnectd/serve.go:46 +0x53
stash.kopano.io/kc/konnect/vendor/github.com/spf13/cobra.(*Command).execute(0xc00008f900, 0xc0000d2280, 0x8, 0x8, 0xc00008f900, 0xc0000d2280)
        /var/lib/jenkins/jobs/kc_konnect/branches/master/workspace/.gopath/src/stash.kopano.io/kc/konnect/vendor/github.com/spf13/cobra/command.go:766 +0x2ae
stash.kopano.io/kc/konnect/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xf96bc0, 0xc000051f70, 0x1, 0x1)
        /var/lib/jenkins/jobs/kc_konnect/branches/master/workspace/.gopath/src/stash.kopano.io/kc/konnect/vendor/github.com/spf13/cobra/command.go:852 +0x2ec
stash.kopano.io/kc/konnect/vendor/github.com/spf13/cobra.(*Command).Execute(...)
        /var/lib/jenkins/jobs/kc_konnect/branches/master/workspace/.gopath/src/stash.kopano.io/kc/konnect/vendor/github.com/spf13/cobra/command.go:800
main.main()
        src/stash.kopano.io/kc/konnect/cmd/konnectd/main.go:31 +0xb8

I would expect no crash but that an error is logged, and the client entry is simply ignored.

small identifier-registration.yaml reproducer (two = in front of redirect uri):

clients:
- application_type: web
  id: wordpress-ucs
  name: Wordpress
  redirect_uris:
  - ==https://ucsmaster.mydomain.intranet/wordpress/wp-admin/admin-ajax.php
  secret: averysecretpassword
  trusted: true

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.