I made this because I've seen too many secrets (API keys, passwords, private keys) shared via Slack and MS Teams etc. I've even had a private API key or two in my gmail inbox because someone DM'd it when I wasn't there. I know some password managers make sharing secrets fairly easy, but I'm often working with clients who don't use the same tools and need a secure way to get .env files and such.
Well put. I agree this is the reality, fantasies aside. No doubt many of us have very productive and effective careers without much leaving the desk. But I like to think that there is fertile ground beyond our natural habitat too, and some of us (like myself) need the encouragement to explore it. At the end of the day though, we'll still need to return to our desk habitat and deliver what we set out to.
This is the question to dwell on I think. I don't know if there are mental ergonomics that apply universally, or even ones that generalise well. For me, I recognise that I think well when I'm physically engaged in some other non-cognitive task, like walking, running, showering, etc.
Another key factor is eliminating the risk of interruptions. I know when I'm at my desk I'm likely to get interrupted, but times and spaces that are interruption free seem to encourage the deepest thought.
I think it'd be interesting to see it used as a search index of README files on github. Though I'm sure you can use some sort of filter to create that anyay
I was getting so impatient waiting for the stubborn programmer animation to finish. Inspect -> sources -> stubborn.js -> ohhhhhh... well done.
On the other hand, I first thought this was a Facebook thing since it started with "Setup your Facebook API Keys in OAuth.io". Perhaps something like "Setup API keys for the provider of your choice in OAuth.io"?
It's worth noting that with 'dotenv' the configuration is stored in a file on the production server before it's loaded into the environment. The security of the method is not based on storing the token in the environment.
The primary advantage I intended was that the secret is confined to one part of the infrastructure (e.g. production server) instead of many (e.g. developer workstations, github, etc).
That's a bit surprising. I'd be interested to read the reasoning behind this design decision as most frameworks I have used store session data in a database rather than directly in the cookie. Well I guess there is a pretty damn good reason given Rails' reputation.
Rails' default session is cookie store, highly recommended is DB. It's a config issue that depends on your app's particular DB setup, so default isn't DB. But in session_store.rb you'll see this comment recommending against the default:
# Use the database for sessions instead of the cookie-based default,
# which shouldn't be used to store highly confidential information
# (create the session table with "rails generate session_migration")
# ShopMobile::Application.config.session_store :active_record_store
# Your secret key for verifying the integrity of signed cookies.
Does this mean that if you use redis/db-backed sessions you can safely ignore this secret_token parameter completely or even delete this initializer?
UPDATE: I just tried to remove it from our environment, and everything seems fine. Unless I'm missing something out, I'd say that's a far better and easier solution overall. It gives you much better control over you session + you don't have to worry about this configuration variable.
I dunno, good question. Maybe something like this: there's some cases where I'll prefer cookies to session data, esp if it's non-volatile data that I can take or leave, like convenience values for the user on the js side, "last selected item" or the like.
I don't necessarily want that data in my session, or as a user attribute that I have to migrate the DB for. If it's a pkid or something that isn't necessarily sensitive, but I also don't want it to be too easy to get at, I might use a signed cookie.
It is often useful to not have to store anything server-side and just round-trip signed data in the cookie. Of course, using a format that can execute code on deserialisation is still a bad idea: a successful attack on the signature should at most let someone impersonate a user, not do anything to an app.
I absolutely agree that there's no easy solution to this (or it would've been "fixed" already).
> some (most) people never open-source their app, and don't mind employees seeing it...
One of my concerns is that people believe it's only a risk if they ever open source their application. While most apps don't have to worry about a motivated attacker in reality, the risk isn't simply secure or unsecure.
It's more a case of 'more difficult' vs. 'much easier' to compromise. I fear many engineers don't think of securing their apps like this. I know I've only recently begun to understand this way of thinking about security and it's changed the way I code.
Love the design overall. Copy is quirky and humorous, but still feels professional.
I agree with others that the vertical navigation is probably not the best.
For some reason that is probably irrational, I hardly ever play product videos but love screenshots. Maybe that's just me.
In this HN post, you've given the app context. ie "Get stuff done collaboratively, from small tasks to complex projects." and "a GTD web app that allows you to manage all your to-dos and projects in a simple visual interface that emulates "pegging" 3x5 cards to a board." That explains a lot for me. However, that information isn't obvious when landing on the homepage. The "How it works" hints at it, but not as well as what you've written here IMO.
Minor things:
Horizontal scroll slightly annoying. I'm using latest Safari (5.0.5) on OS X, 1440 x 990.
The lined page behind the Add Cards to Get Stuff Done box doesn't line with the text for me. Slightly harsh on legibility.
That said, I'm looking forward to trying it out when I've got some time!
Agreed - we can do a better job at clarity on the initial page. And the legibility issue, I'll take a look at that. Thanks for the thoughtful commentary.
I'll reiterate what others have said, it doesn't give me enough information upfront to look for more.
As a web developer, your hook line "Not sure what features to build?" has my attention. "Add fake buttons to your website to test market demand before you build." has me intrigued. Now I'm looking for "how does this work for me?" and "how does this work for my users?"
In the "Ok, how does this work?" section, it stops before the bit I really want to know. "We'll start measuring user demand for your features." How? I think if you described the experience for users of my site, that would clear things up.
Questions and feedback are welcome! https://github.com/danielfone/private-passage