Cloudron Forum

Hi @dualoswinwiz

AES secret encryption requires two things that aren't possible on a Cloudron instance: direct access to the configuration file to set up the encryption key, and the ability to stop and restart the instance during the encryption process. For this reason, you'll need a manual installation to use this feature.

Let me know if you have any questions about the setup!

@DualOSWinWiz With release 1.17.0, there is now a 5-second delay between failed login attempts.

@robi What a pity AppRise doesn't offer its library in Go

At the time I thought tgram URI syntax was a format proposed by Telegram.

In retrospect, I'm a little annoyed at using the format specific to a library.

Sorry @robi, I didn't know about the tgram URI syntax. I'll try to take it into account in a future release.

Hi robi

You have to create a telegram bot and retrieve its API Token and ChatID.

No, but there is at least a one-second delay between each attempt.

Let's imagine a bot attempting to log in with a different password every second. In 5 years, it would have time to test 5x365x24x3600 = 1.5x10^8 combinations.

Now, if you choose a password of only 10 characters from [a-zA-Z0-9], that gives 8.4x10^17 combinations.

Before the bot finds your password, you have at least a few million years ahead of you...

Hello,

Indeed, there must be at least one local admin account, with the purpose of ensuring access is still possible even if the OIDC server becomes unavailable.

If the goal is to secure access, @nebulon 's suggestion (a strong unique password) is the right one.

I have released ctfreak 1.10.1 to facilitate integration with Cloudron: there is no longer a need to wait for the next Cloudron release to enable OIDC.

Here are the details:

https://git.cloudron.io/cloudron/ctfreak-app/-/issues/1

[0.5.0]

• Update Ctfreak to 1.10.0
• Full changelog

@girish https://ctfreak.com/docs/changelog#v1-5-1

https://ctfreak.com/download/version

or

https://hub.docker.com/r/jypsoftware/ctfreak/tags

Great! Thx @nebulon

Noted, @nebulon , thank you for the feedback.

Apparently, according to the OIDC Spec, claims should be returned when no access token is issued, so not only in the case of response_type=id_token:

"However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token"

For response_type=code, an authorization code is returned, not an access token.

I think I have identified the problem: profile scope claims are missing from the OIDC ID token.

I use a cloudron test instance (https://my.testserver.local) and a ctfreak test instance (http://localhost:6700)

Ctfreak calls authorization endpoint (with scope = openid + profile) :

https://my.testserver.local/openid/auth?client_id=aaa&redirect_uri=http%3A%2F%2Flocalhost%3A6700%2Foidc%2Fcallback&response_type=code&scope=openid+profile&state=01H2V4MCC81YQM1ZEZK9RZNZM6

And receive this ID token through its callback URL:

{
  "sub": "testserver",
  "at_hash": "92ETIwTQXH87k71vUy5h_Q",
  "aud": "aaa",
  "exp": 1686689235,
  "iat": 1686685635,
  "iss": "https://my.testserver.local/openid"
}

=> The attribute "name" is missing even though the "profile" scope was requested.

(FYI, "given_name" and "family_name" are missing too even though Ctfreak doesn't use them)

@girish is there a way to add this attribute in the OIDC implementation of Cloudron (this field is filled in the Google and Microsoft OIDC implementations) ?

Thx @marcusquinn !!

@vladimir-d

In the logs, you should have a line of the following type:

Unable to create external user: ...

Can you provide its content?

Also:

• Which authentication provider do you use?
• Is the name of your user properly defined in your authentication provider (empty username could be the cause of the error) ?

Hello,

I noticed that in the list of applications, Ctfreak is not associated with any category (and indeed, I don't see any of the existing categories that would be suitable). What do you think about creating a new category such as "devops", "sysadmin", "scheduling" or "automation"?

Insert directly into the database? I'll have nightmares if we choose that path

I suggest going through the API instead (which will keep the script functional in case of modifications made to the database in future revisions).

On a new running instance of ctfreak (which still has its default admin account), we should launch (only once):

# Install jq & curl
apt install jq curl -y

# Retrieve access token for default user 'admin'
API_ACCESS_TOKEN=$(curl -s --request POST --url 'http://localhost:6700/api/v1/token?grant_type=password&username=admin&password=ctfreak' | jq --raw-output '.access_token')

# Add cloudron auth provider
curl -s --request POST \
  --url http://localhost:6700/api/v1/authProviders \
  --header "authorization: Bearer ${API_ACCESS_TOKEN}" \
  --header 'content-type: application/json' \
  --data '{"name":"Cloudron","enabledFg":true,"authProviderType":"OIDC","oidcAuthProvider":{"clientId":"'$CLOUDRON_OIDC_CLIENT_ID'","clientSecret":"'$CLOUDRON_OIDC_CLIENT_SECRET'","discoveryEndpoint":"'$CLOUDRON_OIDC_DISCOVERY_URL'"}}'

Options to add to manifest:

"oidc": {
    "loginRedirectUri": "/oidc/callback",
    "logoutRedirectUri": "/",
    "tokenSignatureAlgorithm": "RS256"
}

(I haven't tested it with cloudron)

Great!

For OIDC configuration, unfortunately, at the moment, it can only be done through the web interface. However, I'll make a note of it as a possible future enhancement.

@girish

Alright. Here is my account: https://git.cloudron.io/jypelle