Opened 16 years ago
Last modified 5 years ago
#4590 new enhancement
HTTPS support
| Reported by: | anonymous | Owned by: | qualan |
|---|---|---|---|
| Priority: | normal | Component: | OsxRssDashboardWidgetLeopardIntegration |
| Severity: | normal | Keywords: | |
| Cc: | Joshua Mullin, kangy@… | Trac Release: | 0.11 |
Description
Attachments (0)
Change History (11)
comment:1 Changed 16 years ago by
| Cc: | Ryan J Ollos added; anonymous removed |
|---|
comment:2 Changed 15 years ago by
| Cc: | Joshua Mullin added |
|---|
comment:3 Changed 15 years ago by
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?
comment:4 Changed 15 years ago by
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.
comment:5 Changed 15 years ago by
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.
comment:6 Changed 15 years ago by
| Cc: | kangy@… added |
|---|
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).
Your trac instance DOES need to support RSS.
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!
comment:7 Changed 15 years ago by
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"> # <html><head> # <title>401 Authorization Required</title> # </head><body> # <h1>Authorization Required</h1> # <p>This server could not verify that you # are authorized to access the document # requested. Either you supplied the wrong # credentials (e.g., bad password), or your # browser doesn't understand how to supply # the credentials required.</p> # <hr>
comment:9 follow-up: 10 Changed 15 years ago by
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.
comment:10 Changed 15 years ago by
Replying to 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.
Thank you for your help. I would still very much like to get this working ... just need to find the time. Hopefully this weekend!
comment:11 Changed 5 years ago by
| Cc: | Ryan J Ollos removed |
|---|
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).