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
