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
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