Cloudron Forum

I'll use a fresh install then.

Fresh install works as expected.

Just took a look at the redirect uri:

&redirect_uri=%2Fanswer%2Fapi%2Fv1%2Fconnector%2Fredirect%2Fbasic&response_type=code&scope=openid+profile+email&state=state

That looks incomplete?

Also changing the location does not do the trick, which should update the redirect url.

All other apps work without a hitch. Also xxx.xxx is correct.

tried that, still the same error.

nope. xxx.xxx was always xxx.xxx

@BrutalBirdie

root@some-uid:/app/code# printenv | grep -i OIDC
CLOUDRON_OIDC_PROFILE_ENDPOINT=https://my.xxx.xxx/openid/me
CLOUDRON_OIDC_KEYS_ENDPOINT=https://my.xxx.xxx/openid/jwks
CLOUDRON_OIDC_CLIENT_ID=abcdefg
CLOUDRON_OIDC_PROVIDER_NAME=xxx.xxx Cloudron
CLOUDRON_OIDC_AUTH_ENDPOINT=https://my.xxx.xxx/openid/auth
CLOUDRON_OIDC_ISSUER=https://my.xxx.xxx/openid
CLOUDRON_OIDC_DISCOVERY_URL=https://my.xxx.xxx/openid/.well-known/openid-configuration
CLOUDRON_OIDC_TOKEN_ENDPOINT=https://my.xxx.xxx/openid/token
CLOUDRON_OIDC_CLIENT_SECRET= abcdefg

and

root@some-uid:/app/code# mysql --user=${CLOUDRON_MYSQL_USERNAME} --password=${CLOUDRON_MYSQL_PASSWORD} --host=${CLOUDRON_MYSQL_HOST} ${CLOUDRON_MYSQL_DATABASE} -e "SELECT value FROM config WHERE \`key\`='plugin.status'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------------------------------------+
| value                                       |
+---------------------------------------------+
| {"redis_cache":true,"basic_connector":true} |
+---------------------------------------------+

and

root@some-uid:/app/code# mysql --user=${CLOUDRON_MYSQL_USERNAME} --password=${CLOUDRON_MYSQL_PASSWORD} --host=${CLOUDRON_MYSQL_HOST} ${CLOUDRON_MYSQL_DATABASE} -e "SELECT * FROM plugin_config WHERE plugin_slug_name='basic_connector' \G"
mysql: [Warning] Using a password on the command line interface can be insecure.
*************************** 1. row ***************************
              id: 72
plugin_slug_name: basic_connector
           value: {"authorize_url":"https://my.xxx.xxx/openid/auth","check_email_verified":true,"client_id":"abced1234","client_secret":"abcd1234","email_verified_json_path":"email_verified","logo_svg":"","name":"xxx.xxx Cloudron","scope":"openid,profile,email","token_url":"https://my.xxx.xxx/openid/token","user_avatar_json_path":"","user_display_name_json_path":"name","user_email_json_path":"email","user_id_json_path":"sub","user_json_url":"https://my.xxx.xxx/openid/me","user_username_json_path":"preferred_username"}

redirect_uri did not match any of the client's registered redirect_uris

Apache throws OpenID connect error in latest version

No SSL Session requires a complete ssl handshake, whenever a new connection is established. Otherwise Chrome will skip the ssl handshake and omit SNI in ClientHello, only providing the session ticket ID, which the proxy has no way of knowing it.

I'm trying to run cloudron behind a SNI proxy. Sni fails though upon ssl session resumption, because cloudron's nginx uses ssl sessions by default, which do not work reliably over SNI proxies.

SNI proxy means: The proxy routes based on domain to the target, but without tls termination.

If you just put the IP, you are missing the host header. Cloudron itself routes traffic for http per host header internally. An app proxy currently cannot route an upstream request with a certain HostHeader to another IP than what is specified by DNS. Subsequently, you can't circumvent cloudflare, if cloudflare is active for a certain DNS entry, even when the cloudron instance might have access to a network already without routing over cloudflare.

Alternatively that could be achieved by offering a "private secondary domain" by default.

It would be super helpful if the App Proxy would be improved, by not only allowing to specify an upstream Host Header, but also an upstream IP.

This way any cloudflare enabled app could have a private secondary domain that circumvents cloudflare.

It exists for more than 2 years apparently:
https://git.cloudron.io/platform/cloudron-cli/-/blame/master/src/actions.js?ref_type=heads#L665

Why is this endpoint missing from the API docs?

still, it is recommended as the default method for the lamp stack app... How do people do it? Is it really that buggy?

Is it only me or is the app settings File Manager super buggy?

• It does not upload folders?
• It does not delete files when clicking the three dots on a file, without prior highllighting of the file by clicking it somewhere else...
• It does not create new folders...

Ok got it. Is there a particular reason, why a simple upload through the webui is not supported?