Bad URL in the ticket notification email

[gerald.dherbomez@…]

Hello,

In ticket_notify_email.txt template the value of $ticket.link variable is wrong when I receive a notification for a ticket by email. More precisely, the base address is wrong.

For example, I may receive this ticket URL:

Ticket URL: <https://devel.btw.utc.com/trac/project/ticket/1#comment:11>

and instead I receive this one: {{{ Ticket URL: <​https://devel.btw.utc/trac/project/ticket/1#comment:11> }}}

You can see that the base URL contains 4 fields and only the 3 first fields are returned in the email.

Is there a setting to avoid this problem and to get the correct address? Or the number of fields can't overtake 3?

Thank you.

For info, I am using this version of trac: Trac 0.12.1rc1-r10174

[Christian Boos]

Sounds like an InstallationIssue…

What's the value for your [trac] base_url setting, in your trac.ini file?

[Christian Boos]

(and please don't set the milestone field when creating new tickets, as specified in the NewTicketGuidelines)

[anonymous]

Replying to cboos:

Sounds like an InstallationIssue…

What's the value for your [trac] base_url setting, in your trac.ini file?

Hello cboos,

The value of [trac] base_url was empty. I fill it with the correct setting (​https://devel.btw.utc.com/trac/project) and now it is working. Thank you for your quick answer and sorry for the milestone.

[Christian Boos]

Fine, thanks for the feedback!

[dan.mcfadyen@…]

While I know this is an installation issue, I just ran into this on our install of Trac.

I realize that the issue goes away when correctly configured, but I personally think the behavior that happens when it isn't configured correctly is dangerous.

What I observed is that the Ticket URL that gets sent in the e-mail is the URL that the last person changing the ticket used to browse to the ticket. This sounds odd, but here's the example on a windows client I used.

1. Edit your local hosts file to contain a random non publicly resolvable host name for the Trac instance.
2. Browse to that Trac instance using the local only host name.
3. Modify the ticket.
4. E-mail that goes out will have the bogus host name in it.

This sounds like it's possible to exploitable if people have a public Trac server that requires login.

Someone adds a new entry in their local hosts file that tells their machine to go to the public server, but in reality is a URL to a malicious site of a similar name to the public Trac server. They change the ticket in an insignificant way and the e-mail goes out. Someone who receives the ticket doesn't notice the URL and clicks on it, and tries to log in to the malicious server, giving away their credentials.

Wouldn't it be possible to use the servers host name in all instances if not configured? Yes, this may break Trac instances that aren't configured correctly, but one would hope that would lead them to correctly configuring the server instead of having a potential security hole.

[Remy Blank]

Replying to dan.mcfadyen@…:

Someone adds a new entry in their local hosts file that tells their machine to go to the public server, but in reality is a URL to a malicious site of a similar name to the public Trac server. They change the ticket in an insignificant way and the e-mail goes out. Someone who receives the ticket doesn't notice the URL and clicks on it, and tries to log in to the malicious server, giving away their credentials.

You don't need Trac to send such an e-mail, you can compose and send it yourself with any MUA. The only minor difference is that you have to know the e-mail addresses of the intended recipients, whereas this wouldn't be necessary if Trac sends the e-mail.

[dan@…]

True enough, but doesn't grabbing the host name from a client and not the server itself seem inherently wrong?

I don't really mind one way or another now that our Trac install is configured correctly, just wanted to make sure it was a known side effect of the behavior.