Dashboard Causes SSL Warning

[orchardbot]

BrandonJoyce created: https://orchard.codeplex.com/workitem/18965

On an SSL encrypted Orchard deployment, the Dashboard will cause an SSL Warning to be displayed because of the iframe pointing to the advisory page at : http://www.orchardproject.net/advisory

Four quick ways I know of to fix this: 1. Change the iframe to point at an https:// version of the site. 2. Setup a proxy endpoint to point the iframe at. 3. HTTP request the content from the advisory page and send it to the view as html instead of using an iframe. 4. Make the user click an extra link to take them to the advisory page.

I am willing to make this fix, but I'm not sure which way to go. I like the proxy idea the most because it ends up looking the same on the dashboard, doesn't require https setup on advisory page, and also doesn't block the dashboard response time while making the remote call.

I think a short cache of the remote call would also be in order.

[orchardbot]

@bleroy commented:

1 looks like the right solution. 2 not sure what you mean by that. 3 ew, that's bypassing a security measure that's there for a good reason. 4 that defeats the purpose of the feature.

I don't see the point of adding cache if we go for 1 as we should.

[orchardbot]

BrandonJoyce commented:

Ya, I'm all for option #1 if adding ssl isn't a problem. Not something I can help with though.

To be a little more clear on what I meant by option #2. The iframe would point to a route something like "/Dashboard/Admin/Advisory". This route would hit a controller action that returns the advisory information. This action could get the advisory info by making a remote https request if it's not already cached.

If you like #1 better, I'm all for it. It's certainly less coding than option #2.

[orchardbot]

BrandonJoyce commented:

*correction, the action makes an http request for advisory info. The whole point being to work around needing ssl for that page.

[orchardbot]

@bleroy commented:

Then I don't see how 3 is different from 2, but in any case, bypassing a browser security feature to inject remote contents is a Bad Idea ;) So yes, it's #1 and that requires us to set-up SSL on that page on our end.

[orchardbot]

BrandonJoyce commented:

1 sounds good.

I don't want to keep an argument going when we both agree #1 is best, but how is injecting remote content a bad idea? I don't see any added security risk with it. You could change the advisory page to return xml if you wanted something more structured. This is basically what anyone consuming a webservice would do. Eh, maybe I'll catch you at Harvest and we can talk more.

Oh, and the only difference between #2 and #3 is the remote request is done in a different action to prevent the dashboard from taking longer to respond. So, ya, pretty similar though.

[orchardbot]

@sebastienros commented:

Configure https on orchardproject.net and use protocol-less urls in iframes

[orchardbot]

@csurieux commented:

Why do we need this permanent access, are you driving statistics ? I would prefer an option in settings saying 'check for info: never| | on request || always' , just as for windows update.

[orchardbot]

erik_oppedijk commented:

1, configure https

[orchardbot]

@bleroy commented:

No, we are not driving statistics, and actually declared that we would not. The advisory frame is there so that we can easily reach all site admins in case we need to deploy urgent patches such as security patches, and also to notify of new versions.

[orchardbot]

nate_bunton commented:

https does not appear to be working with the following URLs.

https://www.orchardproject.net/advisory

https://orchardproject.net/advisory

[dcinzona]

Any update on this issue @sebastienros ? Also, instead of an iframe, we could use a jquery load html to set the height of the container to fit the content.

Or, if it's easier, add the advisory URI to the gallery: https://gallery.orchardproject.net/advisory