When accessing our sharepoint site via HTTPS, users inside our network receive a prompt stating "Display nonsecure items?".
When accessing the site from outside our network via HTTPS, some images do not display at all. Some links do not function correctly as well.
We have found that this occurs when site administrators create images and/or link and display them using HTTP.
How can we seamlessly integrate HTTP and HTTPS so that we don't have to tell site administrators to use only HTTPS when creating images and links?
I have looked at our Alternate Access mappings, and here is the relevant info there:
http://computername Default http://computername
http://HostName Default http://HostName
http://subdomain.domain.com Intranet http://subdomain.domain.com
https://subdomain.domain.com Extranet https://subdomain.domain.com
http://computername:port Default http://computername:port
http://subdomain2.domain.com Default http://subdomain2.domain.com
http://computername:port2 Default http://computername:port2
...Some explanation:
ComputerName is the name of the server.
HostName is just a single hostname DNS entry we have so people can quickly type for example "Sharepoint" in their address bar.
Subdomain is basically sharepoint.ourdomain.com. pretty self explanitory
Subdomain2 is for our Business Intelligence services server.
We have two entries with port numbers. One goes to central admin. the other gives an error and i'm not sure what its used for (if anything).
I inherited support of this application. I hope things arent too messed up.
So TLDR: How can I get HTTP and HTTPS working seamlessly together inside/outside our network to avoid missing images and invalid links?
Thanks all.
The problem is that the urls in the links and image src are absolute rather than relative.
http://subdomain.domain.com/someimage.gif is always going to use http as its an absolute link.
/someimage.gif is a relative link (the leading / means relative from the hostname) so if this url is from a http site it will use http, from a https site will use https (well technically depends upon the document BASE but you can ignore that for your purposes)
E.g. given the relative URL /somepage/someimage.gif
When accessed from this page
Will mean this
http://example.com/somepage/
http://example.com/somepage/someimage.gif
httpS://example.com/somepage/
httpS://example.com/somepage/someimage.gif
http://NEWDOMAIN.com/somepage/
http://NEWDOMAIN.com/somepage/someimage.gif
and everything will work just fine with no warnings.
The built in CEWP puts all links in as Absolute. To fix -
MSDN - Fixing absolute URLs for all Alternate Access Mappings (AAM) of Content Editor Web Part with a Control Adapter
Related
I had trouble getting AWS CloudFront to work with SquareSpace. Issues with forms not submitting and the site saying website expired. What are the settings that are needed to get CloudFront working with a Squarespace site?
This is definitely doable, considering I just set this up. Let me share the settings I used on Cloudfront, Squarespace, and Route53 to make it work. If you want to use a different DNS provide than AWS Route53, you should be able to adapt these settings. Keep in mind that this is not an e-commerce site, but a standard site with a blog, static pages, and forms. You can likely adapt these instructions for other issues as/if they come up.
Cloudfront (CDN)
To make this work, you need to create a Cloudfront Distribution for Web.
Origin Settings
Origin Domain Name should be set to ext-cust.squarespace.com. This is Squarespace's entry point for external domain names.
Origin Path can be left blank.
Origin ID is just the unique ID for this distribution and should auto-populate if you're on the distribution creation screen, or be fixed if you're editing Origin Settings later.
Origin Custom Headers do not need to be set.
Default Cache Behavior Settings / Behaviors
Path Patterns should be left at Default.
I have Viewer Protocol Policy set to Redirect HTTP to HTTPS. This dictates whether your site can use one or both of HTTP or HTTPS. I prefer to have all traffic routed securely, so I redirect all HTTP traffic to HTTPS. Note that you cannot do the reverse and redirect HTTPS to HTTP, as this will cause authentication issues (your browser doesn't want to expose what you thought was a secure connection).
Allowed HTTP Methods needs to be GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE. This is because forms (and other things such as comments, probably) use the POST HTTP method to work.
Cached HTTP Methods I left to just GET, HEAD. No need for anything else here.
Forward Headers needs to be set to All or Whitelist. Squarespace's entry point we mentioned earlier needs to know where what domain you're coming from to serve your site, so the Host header must be whitelisted, or allowed with everything else if set to All.
Object Caching, Minimum TTL, Maximum TTL, and Default TTL can all be left at their defaults.
Forward Cookies cookies is the missing component to get forms working. Either you can set this to All, or Whitelist. There are certain session variables that Squarespace uses for validation, security, and other utilities. I have added the following values to Whitelist Cookies: JSESSIONID, SS_MID, crumb, ss_cid, ss_cpvisit, ss_cvisit, test. Make sure to put each value on a separate line, without commas.
Forward Query Strings is set to True, as some Squarespace API calls use query strings so these must be passed along.
Smooth Streaming, Restrict Viewer Access, and Compress Objects Automatically can all be left at their default values, or chosen as required if you know you need them to be set differently.
Distribution Settings / General
Price Class and AWS WAF Web ACL can be left alone.
Alternate Domain Names should list your domain, and your domain with the www subdomain attached, e.g. example.com, www.example.com.
For SSL Certificate, please follow the tutorial here to upload your certificate to IAM if you haven't already, then refresh your certificates (there is a control next to the dropdown for this), select Custom SSL Certificate and select the one you've provisioned. This ensures that browsers recognize your SSL over HTTPS as valid. This is not necessary if you're not using HTTPS at all.
All following settings can be left at default, or chosen to meet your own specific requirements.
Route 53 (DNS)
You need to have a Hosted Zone set up for your domain (this is specific to Route 53 setup).
You need to set an A record to point to your Cloudfront distribution.
You should set a CNAME record for the www subdomain name pointing to your Cloudfront distribution, even if you don't plan on using it (later we'll go through setting Squarespace to only use the root domain by redirecting the www subdomain)
Squarespace
On your Squarespace site, you simply need to go to Settings->Domains->Connect a Third-Party Domain. Once there, enter your domain and continue. Under the domain's settings, you can uncheck Use WWW Prefix if you'd like people accessing your site from www.example.com to redirect to the root, example.com. I prefer this, but it's up to you. Under DNS Settings, the only value you need is CNAME that points to verify.squarespace.com. Add this CNAME record to your DNS settings on Route 53, or other DNS provider. It won't ever say that your connection has been fully completed since we're using a custom way of deploying, but that won't matter.
Your site should now be operating through Cloudfront pointing to your Squarespace deployment! Please note that DNS propogation takes time, so if you're unable to access the site, give it some time (up to several hours) to propogate.
Notes
I can't say exactly whether each and every one of the values set under Whitelist Cookies is necessary, but these are taken from using the Chrome Inspector to determine what cookies were present under the Cookie header in the request. Initially I tried to tell Cloudfront to whitelist the Cookie header itself, but it does not allow that (presumably because it wants you to use the cookie-specific whitelist). If your deployment is not working, see if there are more cookies being transmitted in your requests (under the Cookie header, the values you're looking for should look like my_cookie=somevalue;other_cookie=othervalue—my_cookie and other_cookie in my example are what you'd add to the whitelist).
The same procedure can be used to forward other headers entirely that may be needed via the Forward Headers whitelist. Simply inspect and see if there's something that looks like it might need to go through.
Remember, if you're not whitelisting a header or cookie, it's not getting to Squarespace. If you don't want to bother, or everything is effed (pardon my language), you can always set to allow all headers/cookies, although this adversely affects caching performance. So be conservative if you can.
Hope this helps!
Here are the settings to get CloudFront working with Squarespace!
Behaviours:
Allowed HTTP Methods Ensure that you select: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE. Otherwise forms will not work:
Forward Headers: Select whitelist and choose 'Host'. Otherwise squarespace will not know which website they need to load up and you get the message 'Website has expired' or similar.
Origins:
Origin Domain Name set as: ext-cust.squarespace.com
Origin Protocol Policy Select HTTPS so that traffic between the CDN and the origin is secure too
General
Alternate Domain Names (CNAMEs) put both your www and none www addresses here and let Squarespace decide on if to direct www to root or vice-versa (.e.g example.com www.example.com)
You can now configure SSL on CloudFront
HTTPS You can now enforce HTTPS using a certificate for your site here rather than in Squarespace
Setting I'm unsure about still:
Forward Query Strings: recommended not for caching reasons but I think this could break things...
Route53
Create A records for www and root (e.g. example.com www.example.com) and set as an alias to your CloudFront distribution
Scenario goes like this:
Main parts of web site is on one server. All traffic goes over https. I have no control ovet this server.
Themes use css files and images from another server. Also over https. I have full control over this server.
How vulnerable is the main site (how and why) if css files and images would go over http? I am asking only about css and images.
I don't know how relevant is, but server is Apache and language is PHP.
---------------- edit ------------
So far, there is 'a man in the middle' attack who can change css and thus hide my content, introduce new images and add more text.
But can not create live links, or add js...
Here is a good discussion about this topic started by symcbean.
Any unencrypted HTTP connection can potentially be intercepted and modified by men-in-the-middle. That means, any resource you're retrieving via an HTTP connection is untrustworthy; it cannot be confirmed whether it's the original resource as intended. That means an attacker may be able to include resources in your page which you did not intend to include.
In the case of CSS files content can be altered on your site (display: none, content: "Please go to example.com and enter your password"), in the case of images exploits may be introduced (through buggy image decoding client-side), in the case of Javascript entirely arbitrary behaviour may be injected (e.g. sending all key-strokes to a 3rd party server).
A third party may modify those CSS or images to convey different things, either by tampering that data on the fly, or by spoofing the target. The browser would not know if is getting those from a reliable source, and probably would complain about mixed content issues. CSS3 has many features that may bring pictures from another domain or include unintended content.
I'm trying to create a web browser using Cocoa and Swift. I have an NSTextField where the user can enter the website he wants to open and a WebView where the page requested is displayed. So far, to improve the user experience, I'm checking if the website entered by the user starts with http:// and add it if it doesn't. Well, it works for most of the cases but not every time, for example when the user wants to open a local web page or something like about:blank. How can I check if adding http:// is necessary and if I should rather add https:// instead of http://?
You need to be more precise in your categorization of what the user typed in.
Here are some examples and expected reactions:
www.google.com: should be translated into http://www.google.com
ftp://www.foo.com: Should not be modified. Same goes to file:// (local)
Barrack Obama: Should probably run a search engine
about:settings: Should open an internal page
So after you figure out these rules with all their exceptions, you can use a regex to find out what should be done.
As for HTTP vs. HTTPS - if the site supports HTTPS, you'll get a redirect response (307 Internal Redirect, 301 Moved Permanently etc) if you go to the HTTP link. So for example, if you try to navigate to http://www.facebook.com, you'll receive a 307 that will redirect you to https://www.facebook.com. In other words, it's up to the site to tell the browser that it has HTTPS (unless of course you navigated to HTTPS to begin with).
A simple and fairly accurate approach would simply be to look for the presence of a different schema. If the string starts with [SomeText]: before any slashes are encountered, it is likely intended to indicate a different schema such as about:, mailto:, file: or ftp:.
If you do not see a non-http schema, try resolving the URL as an HTTP URL by prepending http://.
I'm building an emailshot tracking function in my ASP.NET site which will serve up a linked image when the email is opened, so allowing me to count the email opens.
It's all above-board, opted-in etc, etc, and I've tried two methods:
calling a .aspx page that serves (direct to the Response stream) a Base64-encoded image stored in a database
calling a .ashx HTTP handler that serves an image from a physical folder
Both of these techniques work absolutely fine - the image is served, and I can process the hit in the page code - if I use my POP email or my Gmail accounts.
However, Hotmail blocks them both. It doesn't even give the option of displaying images - there's no trace of the original link if I View Source on the browser email display.
Links to images only seem to display correctly in the Hotmail browser window if I:
Use an actual domain name in the link (rather than an IP address or localhost for testing) AND
Link to physical files (rather than pages that serve them) using <img src="http://domain/imagefilename.ext"/>.
Is there an alternate approach that will at least give the option of viewing the image? I'm not trying to conceal the tracking in any way - there will usually be other linked images in the emails anyway.
Nor does the thing being served have to be an image - is there anything else that can be served (and hence counted) that isn't treated as suspicious by over-zealous mail servers such as Hotmail?
Cheers.
You can add a querystring value at the end of the url. And then configure IIS to handle that extension.
WELL what are you asking is a nightmare for email server.this same technique is used by spammers to get valid emailid out of junk emailids. For now i can assure you tracking opening of email is impossible using any white hat or gray hat techniques on any reputiable servers.
plese see these links for more details:-
http://emailuniverse.com/ezine-tips/?id=502
https://webapps.stackexchange.com/questions/22662/way-to-ensure-that-my-sent-email-was-read
However dont take myword 'impossible' for granted, there are some protected techineques available but i am not sure about it
http://mailchimp.com/
good luck
I have ssl in my e-commerce web site. At first, browser always asking "do you want to show this web site's content" in all page and when I redirect to mycart page browser shows the same alert like that "This webpage contains content that will not be delivered using a secure HTTPS connection, which could comprise the safety of the entire webpage....Yes...No....". After I clicked to yes, all my sessions get null. Do you have any suggestions for me?
KR,
Çağın
The problem is your secure page is accessing information (scripts, images, etc.) from pages that are not secure. For example if you reference a javascript file (say jQuery) from a nonsecure site (say Google) then certain browsers (like IE) will display this message. You need to search through your references and find these. In other words searching src="http or something along those lines will pull up the nonsecure references.
Depending on what you are referencing you can move those items to your site so that they are now "secure". Also, in some cases changing your reference from src="http to src="https can resolve the problem.
Once you resolve this alert you can check again to see if you are having sessions issues as you could have some other issues to address.