Archive for January, 2016

Being Happy is Not the Absence of Sadness

Sunday, January 31st, 2016

Path

This morning I realized that may path really has shown me something I never expected to see: that being happy does not require the absence of sadness. Not at all. Instead, it now seems to me that being happy - having a giggle, or a good laugh at something - is really about being able to focus on that which is right in front of you, and not what has been happening, or maybe is continuing to happen.

This isn't to say that the sadness isn't there - I felt it very much this morning, but that didn't stop the giggle and smile I got from what I was doing and looking at.

It's been so easy to focus on the darkness - as if it needed fixing, and because it was present, nothing could be positive until that negative was erased. But that's not the case at all. It seems that sometimes you have to accept that erasing the negative will take a little more time than you have right now, and yet that shouldn't stop you from enjoying what you are doing.

Like getting out of debt. It may take you a couple of years, but that's no reason to not enjoy today... you're doing everything you can today to deal with that, but it's just going to take more time to finish off that goal.

Sadness, too.

Smile more. It's not ignorance, or denial... it's just enjoying the thing you are doing right now.

Sharing Login Auth Tokens

Saturday, January 30th, 2016

Javascript

Over the past several months we have built several Clojure/Javascript apps at The Shop, and each one has needed to have some level of authentication, and thankfully, that's all been provided by the Security Service that was already built and maintained by another guy at The Shop. It works, what else would we need? You get authentication tokens (UUIDs) and you can get information about the user based on the token, and you can't really guess an auth token for a user, so they are pretty decently secure.

But they were app-specific because we tied them to the cookies on the pages, and those pages were all from a site that was different for each app we were building. This meant that you'd have to login to three, four apps a day with the same credentials, and still not have a clean, guaranteed way of invoking a page in one app from a page in another.

This is what I wanted to solve.

This morning, it came to me - there had to be a way to store the auth tokens in a cookie that was across the apps, and then just use that as a standard for all apps. Simple. Since it was still secure (enough), we didn't have to worry about folks yanking the token, or even knowing who the token belonged to.

The question was How?

Thankfully, jQuery has this all solved with the domain: tag in the $.cookie() function. All we needed to do was to have a consistent upper-level domain for the apps that also worked for local development.

What I came up with was a simple function:

  function loginDomain() {
    var here = document.domain;
    if (here === 'localhost') {
      return here;
    }
    var parts = here.split('.');
    parts.shift();
    return parts.join('.');
  }

so that we would have a single login for the production hosts on theshop.com and another for the development hosts on da-shop.com. This would work perfectly if I could update all the places that the cookie was accessed.

What I learned was that the accessing of the cookie did not need to have the domain: tag, but setting it - or deleting it did. So for example, to read the token, I'd say:

  var tok = $.cookie('shop-auth-token');
  if (tok) {
    // ...
  }

and no matter where the cookie was saved, if it's in the "domain path", then it's OK. But when I needed to set the cookie I'd need to:

  var exp = new Date();
  exp.setTime(exp.getTime() + (8 * 60  * 60 * 1000));
  $.cookie('shop-auth-token', tok, { domain: loginDomain(),
                                     expires: exp );

and when I needed to invalidate it:

  $.removeCookie('shop-auth-token', { domain: loginDomain() });

Once I got these all set up, and in each application, one login on the specific login domain would then be successfully used on all apps in that domain with this code. Sweet! It worked like a charm, and it took me about 90 mins to figure this out, and put it in all the apps we have.

Big win!