Re: configuring lighttpd proxy for standalone roundup server
"John P. Rouillard" <[email protected]>
| Newsgroups | gmane.comp.bug-tracking.roundup.user |
|---|---|
| Message-ID | <[email protected]> |
Hello Dave:
I'm sorry you're running into trouble. This is an odd error.
In message
<CAETHaKrG1RYBycsdL6n4p3YAc6UJKKcKS3sBKxf-KhJ-tCSeOw@mail.gmail.com> ,
Dave Bender writes:
> I am running into an issue with proxying to a roundup server
>Upon clicking "Lost your login", I correctly get routed to
>
>https://example.com/tracker/name/user?@template=forgotten
>
>However, when I click I get "Request password reset" I get
>
>Invalid Referer
>https://example.com/tracker/name/user?@template=forgotten,
>http://example.com/tracker/
>
>It seems that the referer attribute is not set properly.
Interesting. I can't reproduce this on my trackers.
I don't recognize this error message. I expect:
Invalid Referer: https://example.com/tracker/name/user?@template=forgotten
The second URL, comma and lack of ':' in the message doesn't match
what's in the code. Am I correct that this error message is
displayed in the web interface and is not from the log file.
What is the value of web set to in the tracker section of config.ini?
I assume:
web = https://example.com/tracker/name
where name is the name of the tracker and all trackers are clustered
under /tracker.
Also which version of Roundup are you using?
>Does anyone have a set of lighttpd rules working for a proxy to
>standalone server solution?
>
>This is my present entry for my site in my lighttpd.conf
>
> $HTTP["host"] =~ "(^|\.)example\.com$" {
>
> proxy.header += (
> "map-urlpath" => ( "/tracker/" => "/" )
> ,"https-remap" => "enable"
> )
>
> proxy.server = (
> "/tracker" => (("host" => "127.0.0.1", "port" => 10220))
> )
> }
I haven't used lighttpd in a while. Does the proxy.header
section modify the URL
https://example.com/tracker/name/user?@template=forgotten
to
http://example.com/name/user?@template=forgotten
when it passes it to the standalone Roundup server?
Your original error message included an http: url, I wonder if this
config is incorrectly modifying the Referer header somehow. The CSRF
prevention code requires a matching prefix and "https:" != "http:".
Can you submit the "Request password reset" request while running
the browser debug tools and see what the value is of the Referer
header?
Have a great week.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.