Skip to content

GitLab

  • Menu
    • Projects Groups Snippets
      Help
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • G gitlabhq1
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 21
    • Issues 21
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • gpt
  • large_projects
  • gitlabhq1
  • Issues
  • #464

Closed
Open
Created 13 years ago by Administrator@rootOwner
  • New issue

  • Report abuse

  • New issue

  • Report abuse

incorrect url passed to omniauth login form

Closed

incorrect url passed to omniauth login form

Created by: sunbit

If you deploy gitlab under a subpath

http://some.domain.com/git

the action in the login form for ldap authorization is not valid, as it appears to be hardcoded as "/users/auth/ldap", and when users log in, ends in a invalid path on the domain root. modifying the form to harcoded-including the "git" subpath in the form temporally solves it.

I don't know if this url has to be configured somewhere, or its an error on generating the url not taking into account the real url. I don't have any knowledge of rails nor ruby, but experience with other web frameworks tell me that is something in that way

Linked issues
0


  • Administrator
    Administrator @root · 13 years ago
    Owner

    Created by: patthoyts

    This is giving me trouble also. I got LDAP authentication working fine with gitlab as a standalone rails application. When I integrated this into the apache server using Passenger I moved it to localsite.com/gitlab/ and while everything else works, the LDAP authentication now fails. The problem is that for the LDAP form, the action is set to the absolute url of '/users/auth/ldap/callback'. This is constructed in the OmniAuth::Form code. It looks to me like the url can be passed in as a parameter but I don't see where this should be done in the gitlab application. Something to do with user_omniauth_authorize_path is as close as I can identify.

    By Administrator on 2012-02-29T12:21:42 (imported from GitLab project)

  • Administrator
    Administrator @root · 13 years ago
    Owner

    Created by: carlokok

    same here. if there is setting, it's very well hidden

    By Administrator on 2012-03-08T20:00:08 (imported from GitLab project)

  • Administrator
    Administrator @root · 13 years ago
    Owner

    Created by: patthoyts

    This continues to be a problem in gitlab 2.3 - somewhere in the devise module I think or how gitlab calls that module.

    By Administrator on 2012-03-23T15:46:20 (imported from GitLab project)

  • Administrator
    Administrator @root · 12 years ago
    Owner

    Created by: rspeicher

    I don't have access to an LDAP server for testing, but try this:

    open app/views/devise/sessions/_new_ldap.html.erb

    -<%= form_tag(user_omniauth_callback_path(:ldap), :class => "login-box", :id => 'new_ldap_user' ) do %>
    +<%= form_tag(user_omniauth_callback_url(:ldap), :class => "login-box", :id => 'new_ldap_user' ) do %>

    Change user_omniauth_callback_path to user_omniauth_callback_url.

    By Administrator on 2012-08-11T00:11:43 (imported from GitLab project)

  • Administrator
    Administrator @root · 12 years ago
    Owner

    Created by: riyad

    Closing as "outdated" ... feel free to open a new issue with up-to-date information if this issue still exists.

    By Administrator on 2013-01-11T20:28:32 (imported from GitLab project)

  • You're only seeing other activity in the feed. To add a comment, switch to one of the following options.
Please register or sign in to reply
0 Assignees
None
Assign to
Milestone
No milestone
None
None
Time tracking
Due date
None
None
0
Labels
None
Assign labels
  • No matching results
  • Manage project labels
Confidentiality
Not confidential

You are going to turn on confidentiality. Only team members with at least Reporter access will be able to see and leave comments on the issue.

Lock issue
Unlocked
participants
Reference:

Menu

Projects Groups Snippets
Help