ExpressionEngine CMS
Open, Free, Amazing

Thread

This is an archived forum and the content is probably no longer relevant, but is provided here for posterity.

The active forums are here.

SSL and Expression

June 27, 2007 6:21pm

Subscribe [5]
  • #1 / Jun 27, 2007 6:21pm

    APGWest

    295 posts

    I have a single page that I need to encrypt.  When I put the ‘https’ in front of the URL, it loads but gives the old “This page contains both secure and nonsecure items” in Internet Explorer.  This seems to be stemming from EE embeds, the stylesheet and images being pulled from an image folder.

    One would think there is a simple fix to this but I’m clueless.  Anyone have an idea on what I can do?

  • #2 / Jun 28, 2007 5:24pm

    APGWest

    295 posts

    *taps mic*

    Is this thing on?

  • #3 / Jun 28, 2007 5:31pm

    narration

    773 posts

    Well, as you say, it loads, and it gives the mixed security message.

    So I think the issue is not with EE, but how you set up your page.  If you arrange so that all materials on that page have links from the https: version of your site, then I suspect the messages will go away.

    This would not apply to EE embeds, I think, since they will appear to be coming from your original page.

    I think you are right, though, that the images and stylesheet images do affect, and it should be pretty simple to make their address https: instead of http: for that page. 

    If you have any links or images in the embeds, then yes, you will need to use copies of the embeds in the case of this page, where you’ve similarly updated the addresses to https.

    Off the top of head, but think it’s pretty close anyway - you can try and see.

    Kind regards,
    Clive

  • #4 / Jun 28, 2007 6:58pm

    APGWest

    295 posts

    Thanks for the tips narration.  I’m not sure what you mean by ‘the https: version of your site’?

  • #5 / Jun 28, 2007 7:21pm

    Ingmar

    29245 posts

    In many cases the ressources of a site can be accessed via both http: and https: so simply changing your image references to https: might work.

  • #6 / Jun 28, 2007 7:35pm

    APGWest

    295 posts

    I’ve done all that but I’m still getting the nonsecure/secure error even though it’s graphically showing properly.  I have html links (e.g. <a href=”{path=homepage}”>) pointing to other non-secure places but I wouldn’t think that would be the cause, do you?

  • #7 / Jun 28, 2007 7:35pm

    narration

    773 posts

    Hi svh1,

    I should have used the word ‘view’ instead of ‘version’ - it’s late here, but that’s more clear.

    The key is that when items of your site are viewed on an https: URL, that they all look like they are reached by https: also.

    With relative image links, like ../images/yourimage.jpg, this will happen automatically.  And I think that’s probably the best solution, if it isn’t trouble for you to make all the links relative.

    If your image links are full URLs, like http://your.site.com/images/yourimage.jpg, then there is a problem under otherwise https, since this is not an https secure link.  You can either convert to a relative link as above, or make a different entry with https: prefix, in your top https page or in copies of embed parts, giving those embed parts slightly altered names to keep it straight.

    This would be the same issue for other things than images, but probably you are not using those.  The embeds themselves are shown as part of the primary page, and by themselves won’t cause any problem - just from anything possibly http: inside.

    Hope that helps, and I’m knocking off here in Switzerland.

    Regards,
    Clive

    Thanks for the tips narration.  I’m not sure what you mean by ‘the https: version of your site’?

  • #8 / Jun 28, 2007 7:38pm

    narration

    773 posts

    Hmm.  It might well be the cause - https security is taken very seriously, hence the IE messages.  It’s used, after all, for banks…

    I would try converting those links—and anything at all that turns up on the page as http: only.  You can use view source on from the browser if you are having trouble finding them all.

    They are serious to stop anyone fooling around.

    C.

    I’ve done all that but I’m still getting the nonsecure/secure error even though it’s graphically showing properly.  I have html links (e.g. <a href=”{path=homepage}”>) pointing to other non-secure places but I wouldn’t think that would be the cause, do you?

  • #9 / Jun 28, 2007 8:11pm

    APGWest

    295 posts

    I found it .. and I feel slightly dumb…

    The culprit was some code linking out to a stat tracker.  I removed that and bingo!

    But (there’s always a but, huh?) when I fill out the form and click Submit it get a message that says:

    “Although this page is encrypted, the information you have entered is to be sent over an uncrypted connection and could easily be read by a third party.”

  • #10 / Jun 28, 2007 8:41pm

    narration

    773 posts

    Hmm. I am really half-way to dreamland here, but this sounds you have one more thing to arrange, as the message means it is truly not secure yet.

    This would likely be the url in the <form submit=“http???”> is not https://yourpath.

    It has to be to maintain the SSL connection that secures the data that’s sent in.

    Hope that helps, and is reasonably accurate,
    Clive

    I found it .. and I feel slightly dumb…

    The culprit was some code linking out to a stat tracker.  I removed that and bingo!

    But (there’s always a but, huh?) when I fill out the form and click Submit it get a message that says:

    “Although this page is encrypted, the information you have entered is to be sent over an uncrypted connection and could easily be read by a third party.”

  • #11 / Jun 28, 2007 9:07pm

    APGWest

    295 posts

    Where would I plug that in if I am using FreemForm module and my submit tag was:

    <input type=“submit” name=“submit” value=“SUBMIT” />

    And thanks for the help so far!!

  • #12 / Jun 29, 2007 4:49am

    narration

    773 posts

    Good morning, svh1,

    Well, I went to sleep last night realizing that although the principle was right, something wasn’t in the tags I mentioned to you.

    I have to go out this morning soon, but will leave you clues, and maybe Ingmar will come in with a more targeted comment.

    The HTML tag where you’d expect to find the return URL is <form action=“http://your.url.com/etc.”>.

    In EE, this is taken care of in the form tag, as:

    {exp:weblog:entry_form weblog="default_site" return="site/index" preview="site/entry"}

    the ‘site/index’ in return= is I think equivalent to action= in the HTML form tag.

    Why EE is not automatically inserting https:, or simply using relative paths in its construction of the <form action= for you, I am not sure, since you are on an https: access for the page as you say.

    What I could suggest is to put a full https://your.site.com/site/entry in the return= parameter of weblog:entry_form.  Or similar if you are using some other method in EE.

    Hope that gets the point across and helps, and interested what you find that works.

    Kind regards,
    Clive

  • #13 / Jun 29, 2007 5:12am

    narration

    773 posts

    p.s. of course whatever you find to do with ‘return’, you need to do with any similarly communicating tags you may be using in weblog:entry_form.

    I suggest that you read up on https, html forms, and secure html forms so that you understand better what you’re doing here, as your customers are completely depending on you to keep their personal data secure.

    Google is your friend…and now I really have to go.

    C.

  • #14 / Jun 29, 2007 5:32am

    narration

    773 posts

    It occurs to me to wonder, also, if you are even calling this ‘secure’ page with a full-length https: link.

    I can’t imagine that EE won’t arrange your results etc. properly if you are.

    Again, please read and learn about what you are doing, and which your customers depend upon. 

    These last ‘little questions’ are not side details as we helped you with, but fundamentals of how secure processing needs to work—to be secure.

    Regards,
    Clive

  • #15 / Jun 29, 2007 12:25pm

    Ingmar

    29245 posts

    You might consider automatically rewriting all requests for http:// to their https:// counterpart. The web is full of examples how to accomplish that.

.(JavaScript must be enabled to view this email address)

ExpressionEngine News!

#eecms, #events, #releases