This docker service will accept headers, authenticate, and return the user data
You should be able to resolve auth.reporangler.develop
locally on your computer.
Maybe you need to edit /etc/hosts
file or add to dns?
At first I had instructions which let people decide whether you want to run the manual way or the preconfigured way. The problem is that it becomes really hard to explain correctly to everybody how to do this. So I decided to provide only one way to do this and you can decide whether you want to follow it or not.
The easiest and probably best way to run the services side by side on the same machine is to use the jwilder/nginx-proxy
The reason why you'd want a frontend proxy, is that your machine only has a single port 80. But we run multiple webservices all running on the default port 80. Which gives us a problem. A way around this is to use the docker-compose files in combination with the frontend proxy described here. It automatically configures the frontend proxy to hook up the container without any complex configuration.
This proxy listens on the docker socket for container start/stops and scans the environment variables, looking for recognised configuration parameters it can use to auto-configure the routing/upstream connections between your host machine and the docker container
If you don't want to use this, then I'm afraid you'll need to reconfigure everything to work with your desired setup. But since you're an advanced user. I will let you do that however you want.
network_name=repo_rangler_proxy
docker_image=christhomas/nginx-proxy:alpine
docker network create ${repo_rangler_proxy}
docker run -d --restart always --network=${repo_rangler_proxy} --name=${repo_rangler_proxy} -p 80:80 -p 443:443 -v /var/run/docker.sock:/tmp/docker.sock:ro ${docker_image}
Now once the proxy is up and running, we can run the containers that will be accessible via the proxy
docker-compose stop
docker-compose rm -f
docker-compose build
docker-compose up
NOTE: This command optionally can take the -d
parameter if you want to run in the background
docker ps
curl -vvv http://auth.reporangler.develop:${port}/healthz
It should output
> GET /healthz HTTP/1.1
> Host: auth.reporangler.develop
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.16.0
< Content-Type: application/json
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Powered-By: PHP/7.3.4
< Cache-Control: no-cache, private
< Date: Sat, 31 Aug 2019 17:32:06 GMT
< Access-Control-Allow-Origin: *.reporangler.develop
< Access-Control-Allow-Methods: GET, PUT, POST, DELETE, OPTIONS
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Headers: *
<
* Connection #0 to host auth.reporangler.develop left intact
{"statusCode":200,"service":"http:\/\/auth.reporangler.develop"}
Right now all the users are faked, but you can test the auth to return users by using the following curl commands.
curl -H 'Content-Type: application/json' -X POST -d '{"type":"http-basic", "username": "chris", "password": "thomas"}' http://auth.reporangler.develop/user/login
should return (as long as the faked data is still unchanged):
{"id":1,"username":"chris","groups":["chris","companyA","companyB"]}
a non existence user will do this
curl -H 'Content-Type: application/json' -X POST -d '{"type":"http-basic", "username": "hello", "password": "thomas"}' http://auth.reporangler.develop/user/login
and return:
{"message":"This user does not exist","code":404,"stack":[...stack dump if debug is enabled...]}
The php-service already uses this faked data to retrieve the logged in user and will send the data to the package metadata-service to retrieve the list of packages
There is a (TODO: not secured) REST Api which can be used to configure the authenticated users and what packages they can access. This REST Api is the same api that the command line client (TODO: not created yet) uses in order to do what it does.
These are the allowed groups that users can be assigned to. They define what groups of packages can be made. A typical set of package groups are:
/package-group
: list all registered package groups/package-group/{name}
: get package group by name/package-group/{id}
: get package group by id/package-group
: create a new package group
name:string
]/package-group
: update a package group
id:integer
, name:string
] /package-group/{id}
: delete a package by idUsers are required to know who can login, to what package repository they have access and defined what package groups, when authorized they are allowed to read
/user/login
: attempt a login
type:one_of(database,http-basic,ldap)
,
username:string
,
password:string
,
repository_type:string
]/user/check
: check a token
Authorization: Bearer {token}
]/user
: get a list of all users/user/{name}
: get a user by username/user/{id}
: get a user by id/user
: create a user
username:string
,
password:string
,
repository_type:string
]/user/{id}
: update a user by id
username:string
,
(optional)password:string
,
(optional)repository_type:string
]/user/{id}
: delete a user by id/user/{id}/token
: create a service access token
type:one_of(github)
,
token:string
]/user/{userId}/token/{tokenId}
: delete a service token by id from a specific userA user must be assigned package groups otherwise they can not read any package lists
/user-package-group/user/{id}
: list all mappings by user id/user-package-group/group/{id}
: list all mappings by package group id/user-package-group
: list all mappings/user-package-group
: create a mapping between user and package group
user_id:integer
, package_group_id:integer
]/user-package-group/user/{user_id}/group/{group_id}
: delete a specific mapping between a user and package_group/user-package-group/user/{id}
: delete all mappings for user id (removes a user out of all groups)/user-package-group/group/{id}
: delete all mappings from group id (removes a group from all users)There are no notes