Whether http://acme.help.com and http://acme.com can be considered as same origin? Will it fall under SO restrictions?
Yup, it will fail. In order for origins to be considered same-origin, their scheme, host and port must match. Here are some examples: http://en.wikipedia.org/wiki/Same-origin_policy#Origin_determination_rules
Related
I am somewhat new to web development and have noticed an issue, Browsers seem to not respect the Cache-Control header, I have it set to no-cache, no-store, must-revalidate but yet many of my clients have a cache to begin with (which no-store should prevent according to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#no-store) and the cache is used rather than revalidating with the server leading to broken pages when I change a JS script referenced in a page, only after I tell them to refresh without cache does the browser then fetch the new file but for the browsers to be compliant with the HTTP protocol and spec, don't they need to respect the no-store policy or are none of the major browsers properly compliant with the HTTP protocol/spec and why haven't they been fixed so we don't need workaround solutions like query strings appended to files or using the file's hash or last modification date?
You initially served the resource without cache headers. In that case, the specification allows the client to choose the cache time itself:
Since origin servers do not always provide explicit expiration times,
a cache MAY assign a heuristic expiration time when an explicit time
is not specified, employing algorithms that use other header field
values (such as the Last-Modified time) to estimate a plausible
expiration time.
Different browsers will use different algorithms, but in any case it probably won't be very long. Your problem might have already resolved itself.
As for query strings, I think your confusion comes from conflating at least three distinct issues. One is the HTTP protocol mechanism for communicating cache policies. That is covered in RFC 7234 and mainly involves the proper use of the Cache-Control response header.
A separate issue is what cache strategy to use. That is, which resources should be cached and for how long? There are different ways to approach this, my suggestion would be to follow the best practices discussed here.
Finally, there's how to fix your mistake if you communicated the wrong cache policy and now need an already-cached resource to be ignored or invalidated. In that case, if possible, you could just use a different resource (i.e. change the name). Adding query strings is sometimes suggested here, but it's not a great solution since the standard does not forbid clients from caching resources with query strings.
Getting back to your question, you can temporarily fix your mistake (missing Cache-Control headers) by changing the name of the linked resource, or just by waiting a short time for the heuristic expiration time to pass. Longer term, you should decide how you want your different resources to be cached, and then use Cache-Control to communicate that intent to the browser.
The Openshift 'all-in-one' Vagrant box uses xip.io. The security team at my company has relayed to us that using 'xip.io' for a wildcard DNS could cause some security concerns. So given that 'xip.io' is not an option, how can I get this set up?
We ran into a similar issue at my company. The best answer, which is a bit dire, is that you'll need to set up your own custom DNS. Sorry to say because it is a bit annoying to do but not all that bad. Use this link, it should give you some guidance.
Basically, you'll need to /etc/dnsmasq.conf file to look like:
# Reverse DNS record for master
host-record=master.example.com,192.168.1.100
# Wildcard DNS for OpenShift Applications - Points to Router
address=/apps.example.com/192.168.1.100
The article goes into great detail. I'm not sure how network savvy you are, but if you're not, then I'd suggest roping in one of your ops guys to assist with this. Without a relatively good understanding of networking, setting this up would be quite difficult.
I understand that you can do this without requiring your own DNS.
Quickest way is to manually add required entries to /etc/hosts of your host system, mapping them to IP address that xip.io address would map to.
Alternatively set up dnsmasq something like the following.
$ cat /usr/local/etc/dnsmasq.conf
address=/.10.2.2.2.xip.io/10.2.2.2
address=/.ain1/10.2.2.2
address=/.10.1.2.2.xip.io/10.1.2.2
address=/.cdk/10.1.2.2
$ls /etc/resolver/
ain1 ain1-xip cdk cdk-xip ddns
$cat /etc/resolver/cdk-xip
domain 10.1.2.2.xip.io
nameserver 127.0.0.1
This is cut and paste from elsewhere and I don't use CDK myself so not sure about the IP addresses here, but I understand this shouldn't require you to set up separate DNS. The 'ain1' entry is for the OpenShift Origin all in one VM, which is equivalent to CDK for OpenShift, but using latest Origin upstream version.
Is it possible to use a wildcard SSL certificate to sign other certificates?
i.e. I have bought a root signed wildcard certificate for *.example.com
I want to allow a third party to provide a service for me, on thirdparty.example.com.
Is it possible for me to create a certificate for thirdparty.example.com and sign it using my *.example.com cert? Or do I have to buy a separate cert for the third party.
If this is not possible, is it possible to buy a domain-signing-cert? Just to be clear, I only want to sign certs for .example.com, not a root level (.com) signing cert.
No, you can't (although it is technically possible, but it won't work). Because certificate signing certificate must have two extensions with the following values:
Basic Constraints must be set to CA=True and be marked as critical
KeyUsages extension must have a keyCertSign and cRLSign bits enabled.
is it possible to buy a domain-signing-cert?
yes, it is possible, but it would be very expensive for you (if you don't plan to issue a large number of certificates). Because you will have to pay a huge price for this service, buy required hardware (HSM is mandatory), write documentation (CPS at a minumum) and process external audits to verify whether you comply with provider's CPS (certificate practice statement). Several time ago I wrote an article about root certificate signing: Certification Authority Root Signing.
HTH
Notice how the default domain for stackoverflow is http://stackoverflow.com and if you try to goto http://www.stackoverflow.com it bounces you to http://stackoverflow.com ?
What is the reason for this? Not the tech reason (as in the http code, etc) but why would the site owners want to do this?
I know it's purely aesthetic and I always have host-headers for both www and not, but is there a reason to bounce a user to a single domain, subheaded or not?
Update 1
Not having a subdomain is called a bare domain. Thanks peeps! never knew it had a term :)
Update 2
Thanks for the answers so far - please note I understand that www.domain.com can point to domain.com. This is not a question about if i should offer both or either/or, it's asking why some sites default to a baredomain instead of www subdomains, or vice-versa. Cheers.
Jeff Atwood actually HAS explained why he's gone for bare domains here and here. (Nod to Jonas Pegerfalk for the post :) )
Jeff's post (and others in this thread) also talk about the problems of a bare domain with cookies and static images. Basically, if you have cookies on in a bare domain, then all subdomains are forced also. The solution is to purchase another domain, as posted by the Yahoo Perf Team here.
Jeff Atwood has written a great article about the The Great Dub-Dub-Dub Debate. There is also a blog entry in the Stackoverflow blog on why and how Stackoverflow has dropped the www prefix.
as far as I can tell, it doesn't really matter, but you should pick one or the other as the default, and forward to that.
the reason is that, depending on the browser implementation, www.example.com cookies are not always accessible to example.com (or is it the other way around?)
for more discussion on this, see:
in favor of www
http://faq.nearlyfreespeech.net/section/domainnameservice/baredomain#baredomain - This webhost lists several good reasons for anyone considering doing more than simple webhosting to consider (such as load balancing, subdomains with different content, etc.)
http://yes-www.org - This blog post from 2005 mainly proposed that most internet users needed the www prefix in order to recognize a URL. This is less important now that browsers have built-in searching. Most computer illiterates I know bypass the URL bar entirely.
in opposition to www
http://no-www.org/
and a miscellaneous related rant about why www should not be used as a CNAME, but only as an A RECORD.
http://member.dnsstuff.com/rc/index.php?option=com_myblog&task=view&id=62&Itemid=37
It is worth noting that you can't have CNAME and an NS record on the same (bare domain) name in DNS. So, if you use a CDN and need to set up a CNAME record for your web server, you can't do it if you are using a bare domain. You must use "www" or some other prefix.
Having said that, I prefer the look of URLs without the "www." prefix so I use a bare domain for all my sites. (I don't need a CDN.)
When I am mentioning URLs for the general public (eg. on a business card), I feel that one has to use either the www. prefix or the http:// prefix. Otherwise, just a bare domain name doesn't tell people they can necessarily type it into their browser. So, since I consider http:// an ugly wart on a business card, I do use the www. prefix there.
What a mess.
In some cases, www might indeed point to a completely separate subdomain in a large corporate environment. Especially on an internal network, having the explicit www can make split DNS easier if the Web site is hosted externally (say, at Rackspace in Texas, but everything else is in your office in Virginia.) In most cases, it doesn't matter.
The important thing is to pick one and add an IHttpModule, rewrite rule, or equivalent for your platform to permanently redirect requests from one to the other.
Having both can lead to scary certificate warrnings when switching from http to https if you don't have a wildcard certificate and forget to explicitly redirect based on your site's name (which you probably don't because you want your code to work in both dev and production, so you're using some variable populated by the server).
Much more importantly, having both accepted results in search engines seeing duplicated content--you get dinged for having duplicated content, and you get dinged because your hits are getting split across two different URIs, hurting your rankings.
actually you can use both of them. So it's better to find user your address or some. I mean actually it doesn't really matter tho :)
But putting www as a prefix is more common in public so I guess I'd prefer to use www behind it.
It's easier to type google.com than www.google.com, so give the option of both. remember, the www is just a subdomain.
Also no www is a commonplace these days, so maybe make the www.foo.com redirect to foo.com.
I think one reason is to help with search rankings so that for each page only one page is getting rankings instead of being split between two domains.
I'm not sure why the StackOVerflow team decided to use only one, but if it were me, I'd do it for simplicity. You'd have to allow for both since a lot of people type www by default or out of habit (I'm sure less "techy" people have no idea that there's a difference).
Aside from that, there used to be a difference as far as search engines were concerned and so there was concern about having either a duplicate content penalty or having link reputation split. But this has long since been handled and so isn't much of a consideration at this point.
So I'd say it's pretty much personal preference to keep things simple.
Can anyone please tell me if Certifying Authorities (CAs) are allowed to make modifications to the Certificate Signing Request (CSR) before actually signing the certificate with their own private key?
Specifically, I'd like to know if it's valid for the CA to insert additional fields (such as EKUs) into the cert before adding their signature.
Yes
The Certificate Authority is responsible for enforcing the organisations PKI security policy via its policy files and templates. This may include EKU (extended key usage) attributes.
In reality you are requesting a certificate of a certain type from the CA on behalf of your subject. It is up to the CA to enforce the type of certificates (and the associated uses) that it will issue.
The CA is not actually modifying the request so much as issuing a cert of a permitted type.
I can't speak about CAs in general, but I once ran a Windows Server 2003 network with its own CA, and it's definitely possible to make certreq (through the -attrib option) add additional fields to the CSR before it gets to the CA. Thus, it looks to me like it's possible for the CA itself to do much the same thing.
Your mileage may vary.