StephenOTT / GitLab-Time-Tracking

Lightweight Time Tracking application for GitLab Issue Queues
52 stars 7 forks source link

Application error (InvalidURIError at auth/gitlab #16

Closed jsobiecki closed 8 years ago

jsobiecki commented 8 years ago

Hi,

First at all, thanks for your effort!

And now the problem: I'm not sure if it's my fault (in terms of setup) or it's a bug. I don't have big experience with setting up ruby based apps, so maybe I screwed something.

Reproduction scenario: I was able to run you app, but not on localhost interface, but on sepearate server (docker container). It's plugged to time.gitlab(domain) When I click on "Login" link, I got this error:

application error URI::InvalidURIError at /auth/gitlab bad URI(is not URI?): "http://gitlab(domain)" file: common.rb location: split line: 176

I'm not sure why is the reason for that problem (http://gitlab(domain) is our endpoint) and why this URI is considered as invalid. Is there a setup step I done wrong, or it's app error?

davidscholberg commented 8 years ago

I think I'm receiving a similar error. I have GitLab-Time-Tracking installed on the same server as our gitlab server instead of locally, and when I click on the login link, it redirects to https://gitlab.teamgleim.com/auth/gitlab, which 404s if you're already signed in to gitlab. If you're not signed in, then https://gitlab.teamgleim.com/auth/gitlab will first redirect to https://gitlab.teamgleim.com/users/sign_in to let you sign in, but when you successfully sign in, it redirects back to https://gitlab.teamgleim.com/auth/gitlab, which 404s.

Our gitlab version is 7.14.3.

StephenOTT commented 8 years ago

Sounds like maybe the GL API changed?

StephenOTT commented 8 years ago

When you are not logged into the Time-Tracking app, it will redirect you to login: this will run the following: https://github.com/StephenOTT/GitLab-Time-Tracking/blob/v0.1/app/app.rb#L183-L193

get '/auth/:name/callback' do
    auth = request.env["omniauth.auth"]

    username = auth["info"]["username"]
    private_token = auth["extra"]["raw_info"]["private_token"]
    userID = auth["uid"]

    session["current_user"] = {"username" => username, "user_id" => userID, "private_token" => private_token}

    redirect '/'
end

So from a quick guess, I would think that the callback path has changed for when a user is already logged into GitLab, but not logged into the Time Tracking app.

davidscholberg commented 8 years ago

Actually, I think this is where the problem is: https://github.com/StephenOTT/GitLab-Time-Tracking/blob/v0.1/app/app.rb#L195-L202. It seems to be redirecting to /auth/gitlab on our GitLab server instead of in GitLab-Time-Tracking. Is this intentional? Sorry, I'm not too familiar with ruby.

StephenOTT commented 8 years ago

Where did you install the Time Tracking app?
You set https://gitlab.teamgleim.com as your GITLAB_ENDPOINT? What is the URL of the time tracking app?

The URL for https://github.com/StephenOTT/GitLab-Time-Tracking/blob/v0.1/app/app.rb#L195-L202 uses a relative path against the domain.

StephenOTT commented 8 years ago

application error URI::InvalidURIError at /auth/gitlab bad URI(is not URI?): "http://gitlab.ratioweb.pl/" file: common.rb location: split line: 176

I'm not sure why is the reason for that problem (http://gitlab.ratioweb.pl is our endpoint) and why this URI is considered as invalid. Is there a setup step I done wrong, or it's app error?

@harijari are you sure you container can communicate with the web? / your endpoint?

I am not seeing this issue on localhost. Can you also try running as local host and see if you have the same issue?

StephenOTT commented 8 years ago

@harijari @davidscholberg I am not able to recreate this issue.

Please test as localhost and see if you hit the same issue. If you have the same issues, then please post your env variables (not your App id or app secret), and provide numbered steps to re-create the issue.
I am able to run as local host with GitLab.com as the endpoint and i can be logged into GitLab and re-auth over and over again without logging out. No errors.

jsobiecki commented 8 years ago

@StephenOTT ,

Thanks for info. I'll try at localhost and update this issue.

@harijari are you sure you container can communicate with the web? / your endpoint?

Yes, container has full access to web and endpoint. But maybe I'm missing something. Container exposes only 9292 port. It shouldn't be a problem, but communication to endpoint goes through proxy.

I'll check how local version of time tracking will behave and let you know.

StephenOTT commented 8 years ago

@harijari any luck?

davidscholberg commented 8 years ago

Hey @StephenOTT,

I was finally able to get things working.

Basically, we wanted to run Gitlab-Time-Tracking on the same server that we have Gitlab on, and we wanted all traffic to be over https. So we had set up an nginx reverse proxy for Gitlab-Time-Tracking, but there were 2 problems that we faced:

  1. We initially had Gitlab-Time-Tracking listening on the same address as Gitlab but on a non-standard port. Unfortunately, Gitlab-Time-Tracking redirects didn't include the non-standard port, so we were being redirected to invalid Gitlab URLs. We solved this by setting up a different DNS alias for Gitlab-Time-Tracking and setting up virtual hosts in our reverse proxy to proxy both Gitlab-Time-Tracking and Gitlab. This way, the Gitlab-Time-Tracking redirects don't have to worry about which port to use.
  2. After we had set up the virtual hosts, we were still having a problem with the OAuth callback URL. We set the callback URL to be https, but it looked like Gitlab-Time-Tracking was sending an http URL, which caused Gitlab to tell us that the callback URL was invalid. We were able to solve this by having the reverse proxy send the "X-Forwarded-Proto https" header, so that Gitlab-Time-Tracking always generates https URLs internally.

For anyone curious about our nginx reverse proxy config for Gitlab and Gitlab-Time-Tracking, here it is:

# Gitlab proxy
server {
    listen 80;
    server_name gitlab.teamgleim.com;
    return 301 https://gitlab.teamgleim.com$request_uri;
}
server {
    listen 443 ssl;
    include includes/ssl/teamgleim.com.conf;
    server_name gitlab.teamgleim.com;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        # needed for ruby apps to always generate https URLs
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Ssl on;
        proxy_pass http://localhost:8000;
    }
}

# Gitlab-Time-Tracking proxy
server {
    listen 80;
    server_name gitlabtt.teamgleim.com;
    return 301 https://gitlabtt.teamgleim.com$request_uri;
}
server {
    listen 443 ssl;
    include includes/ssl/teamgleim.com.conf;
    server_name gitlabtt.teamgleim.com;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        # needed for ruby apps to always generate https URLs
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Ssl on;
        proxy_pass http://localhost:8001;
    }
}

Obviously, you'll need to adjust the listening ports of Gitlab and Gitlab-Time-Tracking accordingly.

StephenOTT commented 8 years ago

@davidscholberg nice job! Thanks for the detailed reply. What i can do is expose the http_proxy and the port parameters of gitlab endpoint as ENV vars and I should be able to modify the app to determine if its running on https, and if so accept the https callback.

That would resolve your need for the reverse proxy, correct?

davidscholberg commented 8 years ago

@StephenOTT we're actually okay with our current setup. We still want the reverse proxy so that we can have both Gitlab and Gitlab-Time-Tracking available on port 443 of the same server. Plus, in general I'd rather have nginx handle https connections.

davidscholberg commented 8 years ago

I just wanted to mention (since I didn't make it clear above) that we were able to change the listening address and port of Gitlab-Time-Tracking by passing a couple of cli options to the rackup call:

bundle exec rackup -o 127.0.0.1 -p 8001

Changing the listening address/port of Gitlab itself is well covered in the Gitlab docs.

jsobiecki commented 8 years ago

@StephenOTT,

About my problems. Indeed, installing time tracking application on the same container (machine) solves the issue. In that case, application run correctly.

It is not my use case, through, because I wanted to run gitlab and time tracking app in separate containers. But because it's working when installed locally, I think that problem is on my side, probably network between containers is not set up correctly. I'm not good in debugging ruby based apps, but learning new stuff is always exciting :) I'll check with @davidscholberg approach, hope it will help :)

StephenOTT commented 8 years ago

Do you guys have interest in Time-Tracking being a small cloud service? It was something i had thought about doing for a while, just never got around to it.

It would run as a service and you just point it to your GL instance.

Thoughts?

jsobiecki commented 8 years ago

Uff, I was able to solve my issues as well. Problem was completely on my side and the reason was that I set wrong URL in docker-compose.yml file. Instead of endpoint_url I set "endpoint_url" (quotes!).

And this was quite trival reason why it failed to work for me. So I think that issue is solved from my perspective. :)

@StephenOTT Currently I'm looking for new platform for managing projects, and your tool (in addition to GitLab and kanban board for GitLab) is considered as one of alternatives. So from my perspective, is far too early to say if I'm interested in such cloud service or not. I'm testing various options so far.

But I think, that for people who want to minimise their hosting engagement and use SaaS solutions, such hosted gitlab with your solution + maybe kanban as addition might be interesting. But it's only my private opinion :)

davidscholberg commented 8 years ago

@StephenOTT regarding the cloud service, we prefer to run our own instances of things when we can, but I can see how some people/organizations might be interested in that.

jsobiecki commented 8 years ago

From my perspective this issue is solved. I'm closing it.

StephenOTT commented 8 years ago

:+1:

StephenOTT commented 8 years ago

Always happy to have new feature requests