DEV Community: Simple Software

The Surprising Results Of VueJS Conditional Rendering “v-if”

Corey McCormick — Mon, 12 Oct 2020 00:39:02 +0000

Today was one of those days that everything seemed to go wrong while trying to create a simple VueJS component. The day that you question everything — am I a developer? What am I doing wrong?? How can this not be working??? Deep despair sets in as nothing on Google seems to find your exact problem. We have all been here. Stack Overflow has abandoned you and you must find an answer to the problem all by yourself. Hopefully, my troubles can save you an hour or two in the future.

First, a quick summary of the differences between v-if and v-show. v-if is used when one doesn’t want the DOM element to load onto the page unless the directive is set to true. Toggling the directive will cause the DOM element to be removed from the DOM and then re-inserted firing all associated VueJs life cycle events.

v-showis used to hide and display components within the DOM. The key differences come down to the method in which the elements are removed from the display. Instead of completely remove the DOM element; a CSS property is added display:none. It is important to note that the VueJS lifecycle events will not fire while using v-show.

v-show will always load the element to the DOM which results in a higher initial render but quicker display toggling. See more details in the documentation.

My situation began with a very simple VueJs Component very much like the following. JsFiddle (https://jsfiddle.net/simplycorey/7s20ra1e/11/) Notice that the alert “mounted” only occurs once even though the component should mount multiple times.

<div id="cache-demo">
  <cache-demo :component="component" v-if="component === 'first'"></cache-demo>
  <cache-demo :component="component" v-if="component === 'second'"></cache-demo>
<button @click="component = 'first'">
    First
  </button>
  <button @click="component = 'second'">
    Second
  </button>
</div>

I was attempting to retrieve data in the mounted function as I have done a thousand times before. All seemed normal when the page would load as my components would mount, retrieve their data and show up properly. The problem? Somehow the data was leaking between the two. This blew my mind at first because I had no logic to share the data between them. Checking the props verified that they were receiving the correct information. Continued debugging showed that the mounted, created, destroyed, and other lifecycle events were not firing.

So what gives? It boils down to VueJS attempting to be smart by using an internal cache system to speed up the rendering of the DOM. VueJS will automatically re-use the component and share its data between them. This can cause surprising and frustrating results if you do not know what is going on.

Adding a key attribute will alert VueJS that the components are indeed different and should not use this internal cache system. Instead, the components will fully load each time firing all of the VueJS lifecycle events.

Controlling Reusable Elements with key

Vue tries to render elements as efficiently as possible, often re-using them instead of rendering from scratch. Beyond helping make Vue very fast, this can have some useful advantages. Read more.

Updating our example to the following would provide the results I was looking for. You’ll notice that clicking first or second will always fire the mounted event. JsFiddle (https://jsfiddle.net/simplycorey/3uvde2p7/3/) Notice that “mounted” is always fired when switching the loaded components.

<div id="cache-demo">
  <cache-demo key="first" :component="component" v-if="component === 'first'"></cache-demo>
  <cache-demo key="second" :component="component" v-if="component === 'second'"></cache-demo>
<button @click="component = 'first'">
    First
  </button>
  <button @click="component = 'second'">
    Second
  </button>
</div>

Check out keep.sh if you enjoyed this article and learned something. keep.sh is a free server file transfer system that allows you to send a file with a single command. Try it from your MacBook terminal or any command line the supports curl now:

curl --upload-file ./yourLocalFile.txt https://keep.sh

https://keep.sh/3d1fd43a21/yourLocalFile.txt

I hope this example and explanation will save you some hours in the future!

Detecting and Blocking Vulnerable Curl Requests From Your Users

Corey McCormick — Mon, 12 Oct 2020 00:34:52 +0000

Photo by Markus Spiske on Unsplash

I recently came across a very interesting, and potentially exploitable, problem while working on keep.sh.

I was uploading a file with an Authorization header from a curl client and noticed a strange behavior. During a redirect, the Authorization header stayed with the request even though it was redirected to a different domain.

This sparked my interest as this was clearly undesired behavior and a possible security issue.

A quick Google search led me to CVE-2018-1000007.

When asked to send custom headers in its HTTP requests, curl will send that set of headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is, in particular, a problem for applications that pass on custom Authorization: headers, as this header often contains privacy-sensitive information or data that could allow others to impersonate the curl-using client's request.

We are not aware of any exploit of this flaw.

This security vulnerability has been patched within curl for well over a year but still largely exists in the wild. As of today’s writing, the vulnerability still exists on my MacBook Pro which runs Curl 7.54 natively if you have not specifically updated it using Homebrew or another solution.

This security vulnerability caused a large headache for our service as we rely on the Authorization header for our premium offerings. (Coming Soon!)

This vulnerability prevents our customers from safely downloading their files from our service as it leaks their Authorization information to third party providers.

When you download a file from our service, we currently return a signed URL that redirects to our Digital Ocean space. This allows for your download to start immediately without us having to be a middle-man that fetches the file from our servers and then relay it to you.

This approach speeds up the request and reduces server demand. Herein lies the problem — if your version of curl is vulnerable to a signed redirect, you may be leaking your keys during this redirect.

There was a lot of internal discussion on how to solve this problem to prevent our customers from unknowingly exposing their private keys.

Do we detect the requesting curl version and simply block the request? Do we allow our customers to use a curl version with this security vulnerability and show a warning? Do we abandon the use of redirects?

To make finding a solution even more difficult — we cannot simply detect and rely on the curl version as patches were released for older versions. This means that if you are using an older version of curl it may or may not be vulnerable.

In the end, we had to get creative to solve this complicated issue. We created a two-part system to detect if the incoming requests have this vulnerability and then block the vulnerable requests with a notice.

When a download is first received, our system inspects the User-Agent header for the version of curl you are using. This is done to check if you are using an older version of curl that may be vulnerable.

/**
 * Determines if a curl request may be vulnerable to CVE-2018-1000007
 *
 * @param Request $request
 * @return bool
 */
protected function curlMayBeVulnerable(Request $request)
{
    if (! $request->hasHeader('Authorization')) {
        return false;
    }

    [$agent, $version] = explode('/', $request->userAgent());
    $version = new Version($version);
    $vulnerableVersion = new Version('7.58.0');

    if ($version->lt($vulnerableVersion)) {
        return true;
    }

    return false;
}

Once we determine that you are using a version of curl that may be vulnerable, we send a redirect to a separate secure domain controlled by us.

This behavior mimics the actual security vulnerability without exposing your private keys to an outside organization.

This specially-crafted redirect simply checks if the Authorization headers are still present. If they are (and they shouldn’t be), this means that your current version of curl is vulnerable to CVE-2018–1000007.

After we determine that you are vulnerable to this attack, we actively block the request from continuing and show an error message on your console:

The version of curl you are using has a known security vulnerability that prevents us from safely allowing you to download your files. See [https://curl.haxx.se/docs/CVE-2018-1000007.html](https://curl.haxx.se/docs/CVE-2018-1000007.html) for more information.

Balancing security with convenience is a constant battle. We could have easily just ignored the issue and allowed our customers to expose their Authorization header to an outside organization while retrieving their files.

We believed, even though it can potentially take away from the experience, that blocking all vulnerable requests is the best course of action. This protects our users and their files.

keep.sh is a free file transfer service that allows you to transfer files easily with a simple command line on any server. We recommend you try it today! curl — upload-file file.txt

Thank Your Favorite Projects

Corey McCormick — Sun, 16 Jun 2019 22:48:52 +0000

Over the years, I have used probably 100's of different open source projects throughout my codebases. Many of these do not get the thanks the deserve so here is a small shout out to Spatie(https://twitter.com/spatie_be), the provider of my most used open source projects! Thank you!

Who do you owe a thanks to?

What's your favorite Easter egg you have ever hidden in your work?

Corey McCormick — Fri, 14 Jun 2019 23:25:01 +0000

Most recently, I have been embedding quotes within random code doc blocks as a way to remind myself to have fun. They typically make me laugh years later when I find them.

Here is one from a recent cache clear command I created which displays anytime the command is called:

It can take years to mold a cache. It takes only a fraction of a second for it to be shattered...

What have you been hiding around your codebase?