I ran into a case where I wanted to have a file that exists on my local also exist on a Vagrant VM. I didn’t need it to be shared; using a shared directory. I also couldn’t move the file to the Vagrantfile path and use the default mounted directory to move it. Instead, I needed a way to use scp to push a file from the host to the guest. Vagrant provides an API that is key to making scp work. With some piping and tools; providing the right credentials for scp is easy.

I also commented on StackOverflow

I’ve had plenty of scenarios in development where I have updated a development machine and the credentials are updated causing SSH errors. This happens frequently in Vagrant as well. But it’s simple and quick to remove the old known signature.

When updating your known_hosts; make sure that you understand what you are doing. The known_hosts entries are there to protect you by cryptographically validating a server really is who they say they are. IE: Do Not Delete Things You Don’t Trust.

1
2
3
4
5
6
7

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is

When it comes to first impressions, it can be said a website is made or broken by them. A modern website that relies heavily on scripting is likely self inflicting a performance hit. This hit can be caused by the generic advice given for speeding up a website, ironically. Many web speed tests give an immediate failing grade for not using a content delivery network (CDN) for every single one of your assets. But in the case of critical scripts and styles, this can be the exact wrong advice.

Critical scripts and style are the assets that must load prior to effectively loading content. For instance, a site might use Modernizr to sniff for features to further load content or other scripts. It might use jQuery to create DOM elements and place them on the page. It also might use @media queries to alter, import or change the layout of the page. If any of these situations exist, a new or returning user will have to wait for that file to load on the page prior to being able to view any content. I’m not going to argue if a site needs to be doing those things first, but if it is, then it’s going to cause a ‘hiccup’ for first time rendering. A cached asset may negate this on further loads and that’s why caching and cache control is a good thing to use. But this does nothing to help a first impression.

[caption id=”attachment_571” align=”aligncenter” width=”500”] DNS lookups are killing time[/caption]

/ / / Read More

I’m a fan of David Walsh; whom recently posted a snippet of JavaScript to block an iFrame.

1
2
3

if (top.location != self.location) {
    top.location = self.location.href;
}

[caption align=”aligncenter”]View this on gist.github.com[/caption]

But you can and should invest in a better solution. As one of the solutions pointed out on Stack-Overflow shows you can add the SameOrigin header at the server level. It works and works well. You can even allow certain pages over others.
A quick Apache solution looks like this:

  # ...
  
   # Allow some urls, block all others; whitelisting
   
    # Block any site from applying an iframe.
    Header always append X-Frame-Options SAMEORIGIN 
   
  

This technique works in all browsers and is something you can’t just turn off by disabling JavaScript (ie. It’s more secure).

Also note the Apache parameters for the the whitelisting. If you want to block your entire site from iFrames, then you do not need the LocationMatch. Otherwise, any strings that you put in the regex, if found in the url, will not block iFrames. This is useful if you do not want to block a page thats purpose is to be in a frame (like a bookmarklet script).

For a time we struggled to reset browser styles. Resetting has become the first thing many applications do. Resetting also evolved into normalizing and then into the ‘do all pages need to look the same‘ approach. User Agent (UA) styles are an unfortunate design goal that each version of each browser may apply to elements. There has been little you could do to stop that from occurring; other than implementing the same interactions in pure Bootstrap form and ignoring the elements altogether.

This has begun to change. Largely due to the maturity of web development and the advent of Shadow Dom and Web Components, developers now gain new tools to battle UA styles. Firefox 27 released a very powerful and possibly destructive standard. Now you are able to easily reset all UA styles with a single CSS attribute.

1

*{ all:unset; } /* I do not approve (* is bad perf); but can you feel the weight lifted from the shackles being released?! */

/ / / Read More