Hacker News new | ask | show | jobs
by tubelite 4277 days ago
We use OAuth2 client-side flow. Many pure client-side apps use the same technique - pigshell is not blazing any new trails here.

Only the code you run that's hosted on pigshell.com has access. The permissions are tied to the app-id which is embedded in the code. The access token is persisted in your browser either as a cookie or explicitly in localStorage.

We don't and won't support OAuth 1 (Twitter, Flickr etc), which lacks a pure client-side flow, just to avoid the issue of users having to trust the pigshell.com server to generate (and not leak or misuse) the access tokens.

Here is a rough guide to local setup:

- Check out the git sources, run "make" (some more details here, but reading the Makefile should help)

- set up apache to serve the virtual host pigshell.com (if you want to use Dropbox, you need to create a self-signed SSL certificate and set up https as well)

- modify /etc/hosts and set 127.0.0.1 to point to pigshell.com

This way, static assets as well as redirect URLs from the OAuth2 server will hit your local server rather than pigshell.com