I think I may have this sorted. It seems localised to one production instance only and an acceptance machine with a similar setup to the production machine is not showing the symptoms (and I can't reproduce in dev). It certainly was an odd one. Must be the server configuration. Thanks for all the replies, I think we've all learned something today ;)
cheers, Steve On 11/02/2010, at 6:20 PM, Steve Swinsburg wrote: > 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
