# Ticket #4590 (new enhancement)

Opened 4 years ago

## HTTPS support

Reported by: Assigned to: anonymous qualan normal OsxRssDashboardWidgetLeopardIntegration normal rjollos, jmullin@networkninja.com, kangy@physiosonics.com 0.11

### Description

Hi,

is there a way to get that widget connected to a trac running via HTTPS?

Regards, Fabian

## Change History

### 06/30/09 01:21:00 changed by rjollos

• cc set to rjollos.

### 08/04/09 05:31:57 changed by jmullin@networkninja.com

• cc changed from rjollos to rjollos, jmullin@networkninja.com.

I have tested this with HTTPS, and it works. If you need to use authentication, you can look at ticket #2627 where I've uploaded a version that handles basic auth. It also works with https (tested).

### 08/05/09 09:04:19 changed by rjollos

We can't seem to get the OsxRssDashboardWidgetLeopardIntegration to work with our hosted HTTPS Trac installation. I don't have root access on the server side to look at the logs and such, so its a bit difficult to debug. The status says 'loading' and never changes. Is the XML-RPC plugin required on the server side? I have that installed, but perhaps there is a problem there.

Can you tell me why there is there an entry for Trac User Name and another for User Name in the configuration menu?

### 08/05/09 21:06:27 changed by josmul123

As far as I can tell, no XML-RPC plugin is required. Bear in mind that I picked this project up like four days ago, though. Is the certificate on the HTTPS server self-signed? Perhaps the XMLHttpRequest object is freaking out over not being able to verify the certificate? Just a first thought. Your trac instance DOES need to support RSS. Not sure if they all do, but that could be another possibility. I'll try to develop a version with a debug log and I'll attach it to this ticket so maybe we can see from the client side why you can't connect.

The reason for TRAC User Name vs User Name is that when you use HTTP authentication to get into a TRAC instance, it doesn't necessarily mean it's the same username as your TRAC user, especially for instances where you have a TRAC installation with a generic "one-password" basic authentication. I didn't want to force the system to assume your HTTP username is the same as your TRAC username.

If you have any other feature requests, open up a ticket for them and assign them to me. I'll look into them. This widget is already proving to be massively useful now that I can connect to our HTTP Auth-based user scheme, and I'm all for improving it.

### 08/05/09 21:17:17 changed by josmul123

I just did a little research into this (if you can call google research), and I came across this: http://lists.apple.com/archives/dashboard-dev/2007/Jan/msg00137.html

Apparently there are some other javascript libraries that can handle the self-signed/untrusted certificate situation. I can look into those, but please let me know if that might be the root cause for your HTTPS woes.

### 08/05/09 21:27:05 changed by rjollos

• cc changed from rjollos, jmullin@networkninja.com to rjollos, jmullin@networkninja.com, kangy@physiosonics.com.

I'm fairly sure that my server uses basic HTTP authentication, but I'll need to confirm with my hosting provider.

Is the certificate on the HTTPS server self-signed?

The certificate is signed by GoDaddy and is trusted by the browsers I have used (IE, Firefox, Opera, Chrome, Safari).

I can subscribe to the RSS feed from my timeline. However, after a few days I think that the feed stops updating. I'm assuming this is an authentication issue. I subscribed to the feed and I'll test over the next couple of days.

I'll try to develop a version with a debug log and I'll attach it to this ticket so maybe we can see from the client side why you can't connect.

That would be really great. Thanks for all of your help!

### 08/05/09 21:55:48 changed by rjollos

I can subscribe to an RSS feed, from the Timeline for instance, but the feed does not update. I suspect this is because the feed does not include authentication information. If I try to validate [1] the feed, I see the following:

# <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
# <title>401 Authorization Required</title>
# <h1>Authorization Required</h1>
# <p>This server could not verify that you
# are authorized to access the document
# requested.  Either you supplied the wrong
# browser doesn't understand how to supply
# the credentials required.</p>
# <hr>


### 08/05/09 22:24:21 changed by rjollos

Is it possible my problem is related to Issue #540?

### (follow-up: ↓ 10 ) 08/05/09 22:46:56 changed by josmul123

Regarding this:

"I can subscribe to an RSS feed, from the Timeline for instance, but the feed does not update. I suspect this is because the feed does not include authentication information. If I try to validate [1] the feed, I see the following:"

This is the point of the authentication implemented via ticket #2627. You can try to subscribe to your feed using a url in the format "http://user:pass@yourtrackinstance/path/to/rss/feed" and your browser should automatically supply the credentials, that would give you the same end result as the HTTP authentication implemented in #2627.

That one would probably validate a lot better, as you've supplied credentials at that point.

No need to verify with your hosting company. By looking at that error message, I can clearly see you use HTTP basic authentication.

As far as Issue #540, no, this is not an issue that would apply here, since the "feed reader" in this case is the widget itself, and it knows how to supply authentication information via the fix in #2627. That ticket refers specifically to the fact that you have to supply credentials in the first place.

### (in reply to: ↑ 9 ) 09/03/09 09:02:31 changed by rjollos

Regarding this: "I can subscribe to an RSS feed, from the Timeline for instance, but the feed does not update. I suspect this is because the feed does not include authentication information. If I try to validate [1] the feed, I see the following:" This is the point of the authentication implemented via ticket #2627. You can try to subscribe to your feed using a url in the format "http://user:pass@yourtrackinstance/path/to/rss/feed" and your browser should automatically supply the credentials, that would give you the same end result as the HTTP authentication implemented in #2627. That one would probably validate a lot better, as you've supplied credentials at that point. No need to verify with your hosting company. By looking at that error message, I can clearly see you use HTTP basic authentication. As far as Issue #540, no, this is not an issue that would apply here, since the "feed reader" in this case is the widget itself, and it knows how to supply authentication information via the fix in #2627. That ticket refers specifically to the fact that you have to supply credentials in the first place.

Thank you for your help. I would still very much like to get this working ... just need to find the time. Hopefully this weekend!