search

DependencyTrack / dependency-track

Dependency-Track is an intelligent Component Analysis platform that allows organizations to identify and reduce risk in the software supply chain.
https://dependencytrack.org/
Apache License 2.0
2.58k stars 542 forks source link

Not able to login in dependency track using default login credential. #1074

Open rsumit opened 3 years ago

rsumit commented 3 years ago

Hello

I am new to this tool and I tried to install it on one of my VM having enough ram and cpu for dtrack to work.

Containers are working fine and I don't see any error in the logs both API and forntend ( image attached)

In the UI after adding the default cred - admin:admin, nothing happens. I am not sure what I am missing here but I am attaching some images. Please let me know how can I fix this issue.

dt - error container
nscuro commented 3 years ago

You have to use the external IP or hostname of your VM for the frontend container's API_BASE_URL environment variable, see https://github.com/DependencyTrack/dependency-track/pull/1075/files#diff-c3d30d4845cc6f240782a49f91ce0c35378d163006beee6530bf3448719db99bR92-R96

rsumit commented 3 years ago

@nscuro Thank you. After updating the URL it's working fine. Thanks for creating the PR with this info. I am sure it will help many like me when they go with the first server install.

West-Circle commented 2 years ago

hi, can teach how to update the URL? any steps?

AfshinOnline commented 2 years ago

I waited until all the dependencies from the database were downloaded in the docker logs which took a while and then tried another browser which seemed to work. I had to delete the old volumes and containers to do fresh docker pull.

doggopadre commented 1 year ago

If you used docker to set it up then go to the docker file and put the IP or domain name of your server as the API url. Initially it says localhost:8081/api etc. Because of that CORS will block any attempts to the make the request because it will be using an assumption that its a request from entirely another domain.

AFulgens commented 3 weeks ago

The issue is very old, but still open. It also seems to be an effecitve duplicate of #656, #2205 and there is an unresolved discussion (https://github.com/DependencyTrack/dependency-track/discussions/3534) about the same issue.

A well spent™ 45 minutes today (more than 4 years after this first being reported in #656!) of mine resulted in the following:

Investigation yielded the following:

Confusion ensued. Especially when I have flipped the port mappings and had:

Now the frontend was not accessible, but the API server was responding like it should.

IMPORTANT: A test with binding 8080 and 18080 on the host OS was successful

(doesn't matter which container is which, just keep in mind to sync the API_BASE_URL).

Thus my conclusion is: for some reason (for me on Windows with WSL2) the port forwarding via 8081 of the host is b0rked... I don't have the capacity to investigate this further, I'll just leave it on 18080. Nevertheless seems to be a docker issue, unrelated to Dependency-Track (although maybe related to Alpine? WSL2? Docker? Windows?)

nscuro commented 3 weeks ago

@AFulgens The issue(s) are still open because we want people to find help if they're searching for it. Closed issues are locked after a few days. Technically, we could close all of them since the root cause is not DT itself.

As for your particular issue, ports in the 8xxx range are quite popular so the chance of applications conflicting is definitely higher than zero. I have seen Antivirus and company-internal apps take that port on Windows machines before.

IIRC, exposing a port in WSL will not fail when that port is already taken by an application on the host. There may be a similar constellation where a port is already taken by an app in WSL, but exposing the port via Docker will also not fail. It has been a while since I last used WSL, but I definitely remember battling this before.

AFulgens commented 3 weeks ago

@nscuro I wasn't complaining that it's still open! On the contrary :) I'm just adding my half-educated 2¢ to this issue with a resolution that works for me.

In case the defined port is already taken, on my machine on my current setup, the docker container is not started. (8081 is verified that it was not taken.) In case the port is taken, I receive a Bind for 0.0.0.0:xxxx failed: port is already allocated (in same cases I have seen it not reporting and having the behaviour you describe: silently not binding).

Nevertheless, wanted to add the post so that people know that it's easy to try out to look for other ports than the default docker compose setup.