Private CloudronVersions.json

[robi]

@james said:

No, this is about CloudronVersions.json so the images are not separate from the version files.

Could be on S3 as well since it can do http hosting.

[Lanhild]

@james said:

@robi said:

It would be nice if they could be hosted by the local registry app.

The docker images? That should already work and is close to my above suggestion with a private registry. You'd just need to configure the docker registry in the Cloudron dashboard under /#/docker.

I believe what @robi meant is to be able to store the CloudronVersions.json in a registry, much like what authentik does with blueprints.

[robi]

Following up on this.. @james how do we make this happen with the registry?

[girish]

@robi we are working on this. There is a new container registry app which we have made from scratch. Still finishing things up before we can make an announcement .

[robi]

@girish thanks, can you include basic stats with it?

[robi]

Ohh, also one thing missing is distinguishing of different builds by build number in the UI.

If 2 of 3 are stuck, which ones do I stop?

[huehner]

Hello,
reading this thread i was wondering why can't we just use/offer the classic http with "Basic Authentication" with the username + password embedded in the URL ?

That would (in theory) cloudron avoiding to need to create some separate flow or extra fields
But just use a single/simple url field to (optionally) carry the auth information.

https://user:password@domain/path

That would allow people to use any server / service offering http-basic authentication (essentially any webserver)

Trying that our in cloudron 'Add community app' that immediately fails with "versionsUrl is not a valid URL".

Technically that fails in box/src/community.js but it looks like problem is rather in the frontend here in the onSubmit of the CommunityAppDialog

const [url, version] = versionsUrl.value.split("@");

which seems to use the @ symbol in the URL for some other cloudron specific purpose and thus rejecting otherwise valid urls ?

Note that even allowing those url that would probably need some small change on cloudron backend as fetch API apparently doesn't allow url using url with embedded username/password. But that could be easily avoided converting those if present to the Authorization http header and stripping them from the url object itself.

[james]

Hello @huehner
That should already be possible.
Maybe you can try that?

[huehner]

Hello @james. I tried that before and it fails with the error message i mentioned "versionUrl is not a valid URL".

Trying to explain a bit better what i mean

Problem seems to be that this line in your frontend code
const [url, version] = versionsUrl.value.split("@");

For URL entered in the Cloudron Admin UI of value https://user:password@domain/path

The http-request send by the Admin-UI is
/api/v1/community/app?access_token=<redacted>&url=https://user:password&version=domain/path
which can be seen in Browser Developer tools.

As the frontend code seems use the @ character for its own purpose.
I'm not sure what it is trying to do as in the Publishing documentation there's no information about an @ symbol or some version value in the URL.

With gitlab.cloudron.io not accessible i can't share code link what i talk about for 'split' by @ is this code here

My guess is that this then too short url from that split reaches the backend here: box/src/community.js

and then is no longer a valid URL.

That is just a theory i might be totally wrong (and i don't have a test system i can add some debugging right now)

[joseph]

@huehner said:

With gitlab.cloudron.io not accessible i can't share code link what i talk about for 'split' by @ is this code here

it is git.cloudron.io

[james]

Hello @huehner

One could also integrate an access token into the URL like I have mentioned here:
https://forum.cloudron.io/post/123049

When we prototyped the community app store I even tested this and it worked.

[girish]

@huehner a workaround for now is to use ?username=xx&password=yy . I have fixed the issue that you reported in any case and it will be part of the next release. With the fix you can pass username:password in the URL .