Bug in authorization code for private repos

[lhernanz]

This is related to #31. There is a bug in https://github.com/mcuadros/ofelia/blob/master/core/common.go#L242. The number 2 there should be 1.

The rationale is the following: when using docker hub, the containers are inside a folder of the owner (e.g. mcuadros/ofelia) but when using any other kind of registry, the first element is the name of the registry and the second could be the name of the container already (e.g. registry/container). Therefore, with the current code, this condition is missed and the authentication fails.

Please, notice that I am not entirely sure that the current code is going to work even for dockerhub as credentials from dockerhub should be prefixed with a repo URL too. The code is not including that repo URL in the search to retrieve the credentials.

[jgough]

Hi, I am working on a pull request to fix a bug with private repos that I have discovered. Do you have an example of an image name here so that I can verify works with my new code?

[taraspos]

Hey @jgough, can you explain the issue you found?

I've recently have been looking there as well regarding issue #118.
So what I've discovered that authorization with docker hub may not work because in config.json it is usually stored like:

    "https://index.docker.io/v1/": {
            "auth": "bas64decodeduserandpassowrd==",
            "email": "your email"
    }

however, ofelia tries to parse the registry from the image name. Which in case of docker hub will be mcuadros/ofelia and not https://index.docker.io/v1/mcuadros/ofelia, so lookup in map dockercfg.Configs[registry] fails, because registry is an empty string.

As a potential fix, I was thinking to do something like:

	if v, ok := dockercfg.Configs[registry]; ok {
		return v
	}

	// try to fetch configs from docker's default registry urls
	if registry == "" {
		if v, ok := dockercfg.Configs["https://index.docker.io/v2/"]; ok {
			return v
		}
		if v, ok := dockercfg.Configs["https://index.docker.io/v1/"]; ok {
			return v
		}
	}

	return auth
}

However, not sure how that would still work with fool registry URLs. Because in the config.json it still might be stored like:

  "auths" : {
    "https://account_id.dkr.ecr.us-east-1.amazonaws.com" : {
       ...
    }

While the image will be specified like: account_id.dkr.ecr.us-east-1.amazonaws.com/image:tag (without the https:// prefix), in this case, lookup in map will fail as well.

So I was thinking to check how other tools do that but didn't have time yet :(

[jgough]

My issue was around images of the form host:port/image:tag

buildPullOptions splits the string on ":" characters to get the tag in parts[1], but in this case it is in parts[2] and the parsing completely fails. My pull request addresses this issue.

I'm not that familiar with how the configs are usually stored, but in my case it's under the "auths" key in the config.