@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.
@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:
[0.5.0]
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 !!
In the logs, you should have a line of the following type:
Unable to create external user: ...
Can you provide its content?
Also:
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.
Alright. Here is my account: https://git.cloudron.io/jypelle
@girish license file is here: https://github.com/jypsoftware/ctfreak-cloudron/blob/master/ctfreak-app/LICENSE
Would you prefer me to move the file to the root directory?
Hi
I tried to package ctfreak for cloudron:
https://github.com/jypsoftware/ctfreak-cloudron
I was able to test it successfully on my test Cloudron instance.