Profile cover photo
Profile photo
Eric Eslinger
Eric's posts

Hey oauthers. Does anyone have any insights or links to help me understand the differences between the v1 and v2 version of the oauth2 api? Specifically, will honor my approval_prompt=force parameter, but does not. Documentation seems pretty thin on the ground, and v2 is the default suggested version, so I'm at a loss.

Post has attachment
Making a wrist-rest and tent for my ergodox. This was me just fiddling around - I cut two pieces of 3/8" plywood into roughly the shape of the full-hand ergodox case, got a pice wood for a tent stand, and drilled holes where the bolts in the ergodox case are, so the keyboard fits nicely into place.

Lessons learnt:
1) the tenting leg should be in the other direction; I can cut a wedge out of the 1x2 wood, but I can't cut the entire length of the board at the angle.

2) the platforms need to be about 1/4" - 1/2" in most dimensions. The holes I drilled to receive the keyboard were too close to the edge, and even with careful drilling (not shown) there just wasn't enough material between the holes and the edge for me to feel comfortable with that. Alternatively, I could notch the edges instead of drilling them out. Worth thinking about.

3) the 3/4" thickness of the wrist rest piece is too small. I need about 1", I think.

4) I am positive I'm going to mess up the tenting legs and make them wobbly. Calculating the angles, especially when I intend to put little rubber feet on as well, will be a challenge. I should just plan on leveling it by sanding the bottom of the tenting wedge. Alternatively, I could figure out a way to make a movable, adjustable tenting wedge. This would make storage easier (since it would lay flat) and also let me experiment with actual tenting angles.

5) home depot sells crappy lumber. I'm glad this was cheap, because I messed it all up and gone (and have plenty more to experiment with before I finalize the design and build). But if I'm going to really make something pretty, I should look into buying a few pieces of nice wood. In particular I'm not happy with the "premium" 3/8" plywood. The oak 1x2 was fine, although unremarkable. I figure the size I'm working on here I can probably afford better wood.

6 Photos - View album

Post has attachment

Post has attachment
Interested in an all-new ergonomic mechanical keyboard? is launching their kickstarter very soon. Sign up to the mailing list to get notified on launch. These things are rad.

Full Disclosure - whoever signs up the most mailing list recipients in the next week gets a prototype of the keyboard.

fun with the google client API. If you generate an OAUTH2 token on your server side (either via a direct login or using a refresh token), you can set the oauth token in gapi thusly: gapi.auth.setToken({access_token: token})

Then, you can call gapi.client methods and it'll use that token. This way you don't have to stick your client Id and API key in the frontend javascript for auth purposes (which seems like a terrible idea).

I put all that work behind a little facade pattern in angular, so I can present the google client api stuff to my webapp layer without having to mess around with globally-scoped objects and stuff. It's even testable now, with mocks and so forth. Fancy.

Post has attachment
The guardians of the galaxy soundtrack isn't available on all-access, but all its constituent songs are. So, here's Awesome Mix Vol. 1.

Is there any documentation that indicates how many refresh tokens is too many to request for a particular user? I am testing my application right now, it uses g+ login to generate a "this is user", which I map to an actual user in my system. I also grab the 1-hour access token at that time.

The issue is that I then take that g+ info and re-issue a local token (JWT) that takes a lot longer than an hour to expire. I don't want my users to keep hitting the login button, and I don't want to expose my api id and key on the front-end, so I manage oauth stuff on the server side.

I'm able to grab a refresh token from users the first time they authorize, and finagle getting it again if I do approval_prompt=force at login-time. The problem is that right now, I'm testing stuff out so my database gets wiped occasionally, so my tester accounts end up getting that approval_prompt=force looking login fairly regularly, so I can grab the refreshToken and send it along.

I'm worried about this line from the documentation:

Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working.

Is this something I need to worry about at testing scale? E.g., re-requesting refresh tokens about ten times for about ten users before putting the app into production, at which point I don't think I'll have to request more than once, unless there's a bug.

Post has attachment
My only regret is that this fine album isn't any longer. track 5 in particular is just flat brilliant.

Post has attachment
This week on Gamepunting, +Phil Bowen and I talk about kickstarter campaigns from +GoodmanGames, an Airships Pathfinder campaign, GM resources, +Dyson Logos (who is running a Patreon rather than a kickstarter), and a goblin fantasy football game from Willy miniatures.

Give it a listen!

Post has attachment
I'm now helping co-host the Gamepunting podcast, a podcast about the world of kickstarter tabletop, miniature, and role-playing games. There's a lot of really great campaigns out there, and every two weeks Gamepunting has the newest stuff. The most recent one is my first on the show, but +Phil Bowen has been running it for a year now.
Wait while more posts are being loaded