The interesting thing is that I am unable to reproduce this locally, the iframe is served over HTTPS in my local instance but broken in production. So I'm starting to think it's a Tomcat config issue. I've sent a note out to the sysadmin to check the Tomcat connector settings. One thing is that the prod instance is using Apache in front of Tomcat, but I am just using an SSL enabled Tomcat. I'mm bring up an Apache instance and see if I can break it.
Igor how do I change the rendering pattern? I will try that locally. thanks. Steve On 11/02/2010, at 6:11 PM, Igor Vaynberg wrote: > it may be that this servlet filter is rewriting any redirects. by > default wicket uses redirect to buffer pattern, i doubt velocity or > your other tools are doing something similar. try changing the > rendering pattern in wicket to direct_to_render and see if that helps. > > -igor > > On Wed, Feb 10, 2010 at 8:49 PM, Steve Swinsburg > <steve.swinsb...@gmail.com> wrote: >> It's done by the portal, but it renders an iframe of source: >> >> src=" >> >> https://myserver.edu.au/portal/tool/138a11eb-bcee-4b13-b6c5-d7bf206980ea >> >> Which is the direct link to the tool instance. >> So it appears to be HTTPS, but then reverts to HTTP for some reason. If I go >> to that URL in my browser, with HTTPS intact, it will revert to HTTP in >> front of me. If I grab the iframe source for another tool, say a Velocity >> based tool, the url is similar, still HTTPS, and stays HTTPS when viewing >> it. >> thanks, >> Steve >> >> >> On 11/02/2010, at 3:36 PM, Andrew Lombardi wrote: >> >> what's the code you're using to render the link for the iframe in wicket? >> have you pasted that yet? >> >> On Feb 10, 2010, at 8:32 PM, Steve Swinsburg wrote: >> >> Ok I did that, the Wicket app comes up as as HTTP, however if I do the same >> thing to any that renders in the same style of iframe, it's HTTPS. these >> tools are other display technologies, like JSF, Velocity, etc. >> >> Here's the first Wicket app: >> >> http://server.edu.au/portal/tool/138a11eb-bcee-4b13-b6c5-d7bf206980ea/?panel=Main >> >> Here's a Velocity app in in the same page: >> >> https://server.edu.au/portal/tool/f85ba967-614f-4d5d-81cc-1d931f660b93?panel=Main >> >> The URL of the entire site is: >> >> https://server.edu.au/portal/site/test123/page/3881df23-3931-4928-9d36-702629927ba0 >> >> I have another Wicket app that another developer wrote, same thing, HTTP >> only. So it's only Wicket tools that are doing this. >> >> thanks, >> >> Steve >> >> >> >> On 11/02/2010, at 3:22 PM, Jeremy Thomerson wrote: >> >> What I've suspected all along is that your main page MAY be loaded https, >> >> but that your iframe src is actually ending up http. >> >> do this (in firefox): pull up the app in https, right click in the iframe, >> >> click "this frame", click "show only this frame". is the url that appears >> >> with the iframe content https? >> >> -- >> >> Jeremy Thomerson >> >> http://www.wickettraining.com >> >> >> >> On Wed, Feb 10, 2010 at 9:57 PM, Steve Swinsburg >> >> <steve.swinsb...@gmail.com>wrote: >> >> Exactly. So why are they coming up as HTTP when both the URL and iframe src >> >> are both HTTPS. All resources that Wicket sends from this application are >> >> coming up as HTTP. So I am thinking it still thinks its on HTTP, not HTTPS. >> >> I'll add some logging to the Application init() to figure out if Wicket >> >> thinks its on HTTP or HTTPS. >> >> Could be the iframe? >> >> thanks, >> >> Steve >> >> >> On 11/02/2010, at 2:48 PM, Igor Vaynberg wrote: >> >> your paste does not contain any absolute urls, only relative ones... >> >> -igor >> >> On Wed, Feb 10, 2010 at 7:15 PM, Steve Swinsburg >> >> <steve.swinsb...@gmail.com> wrote: >> >> Yes, the app is rendered in an iframe as my app is deployed into a >> >> portal >> >> container. I pasted that HTML from the iframe source, but here is the >> >> whole >> >> lot: >> >> http://pastie.org/819416 >> >> Line 21 has the import for the css. >> >> Line 55 is a ContextImage >> >> The iframe source >> >> is: src=" >> >> https://myserver.edu.au/portal/tool/138a11eb-bcee-4b13-b6c5-d7bf206980ea?panel=Main >> >> " >> >> and that renders the tool. >> >> Using the padlock in the bottom right of Firefox, and analysing the >> >> Media, >> >> gives all images that are loaded on the page, and all of those that come >> >> from this app are http only, the rest that come from the portal >> >> container >> >> are https as normal. Changing the address to http and refreshing makes >> >> the >> >> portal container urls change to http as expected. >> >> thanks, >> >> Steve >> >> On 11/02/2010, at 1:45 PM, Jeremy Thomerson wrote: >> >> Well, can you paste the actual html that is generated that links to your >> >> stylesheet on the https page? Because what you pasted earlier was a >> >> relative URL, which would mean that the browser would make it https as >> >> well. So, they're some piece of the puzzle we haven't received yet. >> >> Perhaps you could browse to the https page, view source, copy the whole >> >> source into pastebin and send it? >> >> Are you using iframes or anything? >> >> -- >> >> Jeremy Thomerson >> >> http://www.wickettraining.com >> >> >> >> On Wed, Feb 10, 2010 at 8:29 PM, Steve Swinsburg >> >> <steve.swinsb...@gmail.com>wrote: >> >> Edit: ... thats how I can confirm it was broken, because when I change >> >> it >> >> to http it works. >> >> >> >> On 11/02/2010, at 1:26 PM, Steve Swinsburg wrote: >> >> Yes. And thats how I can confirm it breaks when I change the address to >> >> just http. Both http and https work on this particular site which makes >> >> it >> >> easy for testing. >> >> The address is https and then it renders the content in an iframe with >> >> source attribute that is also https (I'm working in a portal framework). >> >> >> >> On 11/02/2010, at 1:00 PM, Andrew Lombardi wrote: >> >> and the URL for your page in the Location bar *is* https? >> >> On Feb 10, 2010, at 5:55 PM, Steve Swinsburg wrote: >> >> What I meant to say was that the ContextImage and CSS looks fine, >> >> however the actual URLs it renders are all HTTP, not HTTPS when they >> >> should >> >> be. The first resource link is clearly broken. >> >> cheers, >> >> Steve >> >> >> >> On 11/02/2010, at 12:13 PM, Steve Swinsburg wrote: >> >> Hi Jeremy, >> >> For resources its rendered as >> >> >> http://myserver/webapp/context/resources/org.apache.wicket.ajax.AbstractDefaultBehaviour/indicator.gif >> >> For a ContextImage its: >> >> <img src="images/no_image.gif"/> >> >> For the CSS include its: >> >> <link rel="stylesheet" type="text/css" href="css/styles.css" /> >> >> It all looks fine except the styles.css that has the classes are >> >> sending the images over HTTP, and they declare like: >> >> >> >> .someClass { >> >> background-image: url(/library/image/silk/icon.png); >> >> } >> >> >> >> >> cheers, >> >> Steve >> >> >> >> >> >> On 11/02/2010, at 11:53 AM, Jeremy Thomerson wrote: >> >> What URL does Wicket generate in your HTML? >> >> -- >> >> Jeremy Thomerson >> >> http://www.wickettraining.com >> >> >> >> On Wed, Feb 10, 2010 at 6:46 PM, Steve Swinsburg >> >> <steve.swinsb...@gmail.com>wrote: >> >> Note that this also happens for resources that Wicket serves, eg: >> >> >> resources/org.apache.wicket.ajax.AbstractDefaultBehaviour/indicator.gif >> >> and ContextImages. >> >> Can I detect HTTPS and force Wicket to serve content over HTTPS? >> >> thanks, >> >> Steve >> >> >> On 11/02/2010, at 11:14 AM, Steve Swinsburg wrote: >> >> The request for the CSS is a renderCssReference call: >> >> response.renderCSSReference("css/styles.css"); >> >> So it should be relative to what ever protocol is being used? >> >> >> >> >> >> On 11/02/2010, at 10:58 AM, jason lea wrote: >> >> The background image url is relative to the css file. Is the >> >> request for >> >> the css file https? >> >> On Thu, Feb 11, 2010 at 12:35 PM, Steve Swinsburg < >> >> steve.swinsb...@gmail.com >> >> wrote: >> >> >> Hi all, >> >> >> I have a Wicket application that is running over HTTPS but is >> >> rendering >> >> some images (like background images from css) over HTTP only. This >> >> causes >> >> the 'This page contains unsecure items' type warning and inspecting >> >> the >> >> Page >> >> Info from Firefox shows they are indeed being served over HTTP only. >> >> >> Luckily I can switch this particular site to be just HTTP and as >> >> soon as I >> >> do that, the issues go away (obviously since its all just HTTP now). >> >> However >> >> I cannot just run the entire app over HTTPS only, as this >> >> application is >> >> deployed in many different contexts by many different institutions >> >> and they >> >> may be running it over HTTP only. >> >> >> So can I force Wicket to render everything via HTTPS if its running >> >> over >> >> HTTPS and just normal HTTP if its running as such? >> >> >> Note that I have things like: >> >> >> .someClass { >> >> background-image: url(/library/image/silk/icon.png); >> >> } >> >> >> so I can't just prefix all URL links since most of them come from >> >> the CSS. >> >> >> thanks, >> >> Steve >> >> >> >> >> >> -- >> >> Jason Lea >> >> >> >> >> >> >> >> >> To our success! >> >> Mystic Coders, LLC | Code Magic | www.mysticcoders.com >> >> ANDREW LOMBARDI | and...@mysticcoders.com >> >> 2321 E 4th St. Ste C-128, Santa Ana CA 92705 >> >> ofc: 714-816-4488 >> >> fax: 714-782-6024 >> >> cell: 714-697-8046 >> >> linked-in: http://www.linkedin.com/in/andrewlombardi >> >> twitter: http://www.twitter.com/kinabalu >> >> Eco-Tip: Printing e-mails is usually a waste. >> >> ======================================================== >> >> This message is for the named person's use only. You must not, directly >> >> or indirectly, use, >> >> disclose, distribute, print, or copy any part of this message if you are >> >> not the intended recipient. >> >> ======================================================== >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> >> >> To our success! >> >> Mystic Coders, LLC | Code Magic | www.mysticcoders.com >> >> ANDREW LOMBARDI | and...@mysticcoders.com >> 2321 E 4th St. Ste C-128, Santa Ana CA 92705 >> ofc: 714-816-4488 >> fax: 714-782-6024 >> cell: 714-697-8046 >> linked-in: http://www.linkedin.com/in/andrewlombardi >> twitter: http://www.twitter.com/kinabalu >> >> Eco-Tip: Printing e-mails is usually a waste. >> >> ======================================================== >> This message is for the named person's use only. You must not, directly or >> indirectly, use, >> disclose, distribute, print, or copy any part of this message if you are not >> the intended recipient. >> ======================================================== >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org >
smime.p7s
Description: S/MIME cryptographic signature
