New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optionally send custom headers in authentication call #1018

Merged
merged 1 commit into from Jul 15, 2016

Conversation

Projects
None yet
2 participants
@f3ndot
Copy link
Contributor

f3ndot commented Jul 8, 2016

Complex systems that offer Two Factor Authentication with their OAuth 2.0 implementation need to send additional context via the HTTP headers. This pattern has been observed in the wild by such systems such as GitHub. Because of the restrictions of OAuth 2.0 RFC, only headers can be used for additional context, not request/response bodies.

This could be seen as a counterpart to #1012, where using both features allow bi-directional context enabling 2FA, brute force lockouts, etc.


An different approach that functions the same would be

authenticator.set('headers', { foo: 'bar' });
authenticator.authenticate('username', 'password');

Which is consistent with clientId but I feel like my approach may be more intuitive for the user.

@marcoow

This comment has been minimized.

Copy link
Member

marcoow commented Jul 10, 2016

I'm actually not 100% familiar with the use cases for custom headers for OAuth 2.0. I think the main question is whether headers are actually static and would always has the same value for all requests the app makes (like clientId) in which case I think a property for setting them would be a better fit or whether they might be dynamic so that their value might not be known until calling the session's authenticate method in which case introducing an additional argument might be the better API choice indeed.

@f3ndot

This comment has been minimized.

Copy link
Contributor

f3ndot commented Jul 10, 2016

Ah! My bad for not explaining. The header contains a dynamic value, which is the One Time Pad code a user receives on their device:

Client: HTTP POST /api/oauth/tokens (username & password payload)
Server: HTTP 401 (response has header 'X-Vendor-OTP: required')
Client: HTTP POST /api/oauth/tokens (username & password payload, and 'X-Vendor-OTP: 123456' header)
Server: HTTP 200

In the context of 2FA, the headers in the response inform the user that their authentication is insufficient (although username & password succeeded) and additional information is required. The user then either receives their SMS code or opens their offline 2FA app to which they replay their credentials, but sending the 30 second challenge code or One Time Pad to the server for verification.

OTP values are:

  • Generated from a unique secret to each user
  • Are time based, expiring every 30 seconds
@marcoow

This comment has been minimized.

Copy link
Member

marcoow commented Jul 11, 2016

Thanks for the explanation! I guess your idea would be to make the first POST in the example yourself (not using the session's authenticate method) and then for the second request pass the user's credentials as well as the 2FA code as a header to the session's authenticate method?

I wonder whether there's a way to somehow combine all of that in the authenticator so that you'd only have to invoke the session's authenticate method once with the user's credentials and the authenticator would handle the 2FA stuff, e.g. via calling a callback that would return the 2FA code or so…

@f3ndot

This comment has been minimized.

Copy link
Contributor

f3ndot commented Jul 15, 2016

@marcoow My idea would be two authenticate calls. The design of Two-Factor Auth is to not "show your hand" that an account has it enabled. For all intents and purposes, the first authentication call must be fully formed & valid except, if said account has 2FA-enabled, it's forced to reject despite valid authentication. This rejection, combined with context enabled by #1012, informs the Ember app that a subsequent authenticate call must be performed but requires an additional OTP code sent through the request header (this PR).

It is up to the developer, who wants to enable 2FA with your addon, to check the server's response headers, drive UX if present, then allow the user to trigger a second authentication attempt.

Not all accounts in a system would have 2FA, so the first call must be the regular ember-simple-auth code paths. It's the optional presence of headers that can require an additional request, which is so similar to the first (just additive request headers), so it makes sense to re-use ember-simple-auth again.

An example login controller would look like this, in my mind:

// A login controller of some sort

// ...
username: '',
password: '',
otpCode: '',
displayAdditonalOtpField: false,

actions: {
  login() {
    let headers;
    if (this.get('displayAdditonalOtpField')) {
      headers['X-Vendor-OTP-Code'] = this.get('otpCode');
    }

    this.get('session').authenticate('authenticator:oauth2', email, password, headers).then(() => {
      this.send('doSuccessfulLoginStuff');
    }, (xhrObject) => {
      if (xhrObject.getResponseHeader('X-Vendor-OTP') === 'required') {
        // User successfully authenticated, backend wants additional verification.
        // Shows verification code field for user to fill. They then can re-trigger `login` action
        this.set('displayAdditonalOtpField', true);
        return;
      }
      this.send('doFailedLoginStuff');
    });
  },
  // ...
}
@f3ndot

This comment has been minimized.

Copy link
Contributor

f3ndot commented Jul 15, 2016

I'm open to, but can't think of a way, for us to encapsulate this multiple authenticate call logic into the addon since it requires additional user input at the second stage and different developers will have different UX flows for controlling their 2FA experience.

The example I illustrated above is the cleanest way, in my opinion, with the ember-simple-auth authenticate call being written once and headers being set depending on the state of the app-- which is dictated by the backend failure context.

@marcoow

This comment has been minimized.

Copy link
Member

marcoow commented Jul 15, 2016

Yeah, that makes sense.

@marcoow marcoow added this to the 1.2 milestone Jul 15, 2016

@marcoow marcoow added the enhancement label Jul 15, 2016

merge(options.headers, clientIdHeader);
}

if (keys(options.headers).length === 0) {

This comment has been minimized.

@marcoow

marcoow Jul 15, 2016

Member

if (isEmpty(keys(options.headers))) {

@f3ndot

This comment has been minimized.

Copy link
Contributor

f3ndot commented Jul 15, 2016

@marcoow thank you so much. By you accepting these two enhancements, you've unblocked the ability for Ember developers to implement both Two-Factor Authentication and detecting Brute Force lockouts ❤️

@marcoow

This comment has been minimized.

Copy link
Member

marcoow commented Jul 15, 2016

just one minor style comment

Justin Bull
Optionally send custom headers in authentication call
Complex systems that offer Two Factor Authentication with their OAuth 2.0 implementation need to send additional context via the HTTP headers. This pattern has been observed in the wild by such systems such as GitHub. Because of the restrictions of OAuth 2.0 RFC, only headers can be used for additional context, not request/response bodies.

This could be seen as a counterpart to #1012, where using both features allow bi-directional context enabling 2FA, brute force lockouts, etc.

@f3ndot f3ndot force-pushed the f3ndot:optionally-send-custom-headers-in-authentication-call branch from 066062a to 80630a5 Jul 15, 2016

@marcoow marcoow merged commit fb8c8ad into simplabs:master Jul 15, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@f3ndot f3ndot deleted the f3ndot:optionally-send-custom-headers-in-authentication-call branch Jul 15, 2016

josemarluedke added a commit to josemarluedke/ember-simple-auth that referenced this pull request Jul 21, 2016

Optionally send custom headers in authentication call (simplabs#1018)
Complex systems that offer Two Factor Authentication with their OAuth 2.0 implementation need to send additional context via the HTTP headers. This pattern has been observed in the wild by such systems such as GitHub. Because of the restrictions of OAuth 2.0 RFC, only headers can be used for additional context, not request/response bodies.

This could be seen as a counterpart to simplabs#1012, where using both features allow bi-directional context enabling 2FA, brute force lockouts, etc.

arjansingh added a commit to arjansingh/ember-simple-auth that referenced this pull request Jul 27, 2016

Optionally send custom headers in authentication call (simplabs#1018)
Complex systems that offer Two Factor Authentication with their OAuth 2.0 implementation need to send additional context via the HTTP headers. This pattern has been observed in the wild by such systems such as GitHub. Because of the restrictions of OAuth 2.0 RFC, only headers can be used for additional context, not request/response bodies.

This could be seen as a counterpart to simplabs#1012, where using both features allow bi-directional context enabling 2FA, brute force lockouts, etc.

marcoow added a commit that referenced this pull request Jul 28, 2016

Fastboot Feature Branch (#1032)
* ignore store events while the session is busy (#965)

* 1.1.0-beta.5

* 1.1.0

* Check for resourceName in response in Devise Authenticator

* change cookie default key names to be rfc2616 compliant (#978)

fixes #977

* Test for session service data being set with Ember.set (#972)

* code/docs cleanup

* Add tokenRefreshOffset property to OAuth2PasswordGrantAuthenticator (#840)

tokenRefreshOffset determines the offset seconds before the token
expiration to refresh the token. This is randomized so as to reduce
race conditions between multiple tabs from refreshing at the same time.

This is configurable because in some cases, the offset randomization
needs to be increased to decrease the probability of the above mentioned
race conditions.

Once more case would be in slow internet connections, you make a call to
refresh the token but the server doesn't process it in time (or receive
it in time), the server will check and the token that you sent up is now
expired so the refresh will fail.

* cleanup transition usage in authenticated and unauthenticated route mixins (#992)

no issue
- fixes potential test timing issue
- removes unecessary abort call

* [BUGFIX] Remove Ember.Logger (#993)

Ember.Logger is not substituted by noops in production.

More info in emberjs/guides#1467

* [WIP] Validate server responses in authenticators (#957)

* Validate response data in devise authenticator

* Validate response data in OAuth2 authenticator

* Add tests for oauth2 data validations

* Add tests for devise data validations

* Remove unncessary validations

* Refactor 'restore' in devise authenticator

* Fix test timeout errors

* Minor cleanup

* Consider resource name when validating response

* Refactor devise authenticator _validate method

* update dependencies (#1004)

This updates Ember, Ember Data, Ember CLI etc. to the latest
versions. This also fixes a lot of JSCS warnings that were introduced
by the latest version of ember-suave.

* Use the term "squash" when referring to collapsing commits into one (#1011)

That's consistent with the term used in git-rebase and with the general public.

* Add rejectWithXhr to optionally reject with XHR vs response body (#1012)

Allows ember apps using ember-simple-auth to receive the whole XHR object if the backend fails, instead of the response body, if they so choose.

In the case of OAuth 2.0 backends, it's been a pattern in the wild to use X- headers to send context as to why a grant has failed. Examples include API throttling, brute force lockouts, and OTP/two-factor authentication information.

Selfishly, I require this change so my application can be notified when the API has locked out an account due to suspicious activity via an X- header.

The decision to expose it as an option was chosen so backwards compatibility is maintained and keeps the addon simple for those who need not be concerned with complex backends.

* Add fastboot-dist to npmignore (#1015)

* Optionally send custom headers in authentication call (#1018)

Complex systems that offer Two Factor Authentication with their OAuth 2.0 implementation need to send additional context via the HTTP headers. This pattern has been observed in the wild by such systems such as GitHub. Because of the restrictions of OAuth 2.0 RFC, only headers can be used for additional context, not request/response bodies.

This could be seen as a counterpart to #1012, where using both features allow bi-directional context enabling 2FA, brute force lockouts, etc.

* [fastboot-compatibility] initial work

* [fastboot-compatbility] improve support

* [fastboot-compatibility] Use ember-cookies@0.0.7

ember-cookies 0.0.6

ember-cookies@0.0.7

* [fastboot-compatbility] fix ember-build-cli.js

* [fastboot-compatibility] fix route mixin transitions

* [fastboot-compatibility] Update `session-stores/cookie` with `typeof` guard (#1)

* [fastboot-compatiblity] fix tests

* Use apiHost config for dummy app.

better name for api host conf setting

fix dummy app API endpoints

* Helpful instructions for `npm run fastboot`

* Restore cookie session renewal

* Fix various rebase issues

* ember-cli-fasboot@1.0.0-beta.7

marcoow added a commit that referenced this pull request Jul 28, 2016

Fastboot Feature Branch (#1032)
* ignore store events while the session is busy (#965)

* 1.1.0-beta.5

* 1.1.0

* Check for resourceName in response in Devise Authenticator

* change cookie default key names to be rfc2616 compliant (#978)

fixes #977

* Test for session service data being set with Ember.set (#972)

* code/docs cleanup

* Add tokenRefreshOffset property to OAuth2PasswordGrantAuthenticator (#840)

tokenRefreshOffset determines the offset seconds before the token
expiration to refresh the token. This is randomized so as to reduce
race conditions between multiple tabs from refreshing at the same time.

This is configurable because in some cases, the offset randomization
needs to be increased to decrease the probability of the above mentioned
race conditions.

Once more case would be in slow internet connections, you make a call to
refresh the token but the server doesn't process it in time (or receive
it in time), the server will check and the token that you sent up is now
expired so the refresh will fail.

* cleanup transition usage in authenticated and unauthenticated route mixins (#992)

no issue
- fixes potential test timing issue
- removes unecessary abort call

* [BUGFIX] Remove Ember.Logger (#993)

Ember.Logger is not substituted by noops in production.

More info in emberjs/guides#1467

* [WIP] Validate server responses in authenticators (#957)

* Validate response data in devise authenticator

* Validate response data in OAuth2 authenticator

* Add tests for oauth2 data validations

* Add tests for devise data validations

* Remove unncessary validations

* Refactor 'restore' in devise authenticator

* Fix test timeout errors

* Minor cleanup

* Consider resource name when validating response

* Refactor devise authenticator _validate method

* update dependencies (#1004)

This updates Ember, Ember Data, Ember CLI etc. to the latest
versions. This also fixes a lot of JSCS warnings that were introduced
by the latest version of ember-suave.

* Use the term "squash" when referring to collapsing commits into one (#1011)

That's consistent with the term used in git-rebase and with the general public.

* Add rejectWithXhr to optionally reject with XHR vs response body (#1012)

Allows ember apps using ember-simple-auth to receive the whole XHR object if the backend fails, instead of the response body, if they so choose.

In the case of OAuth 2.0 backends, it's been a pattern in the wild to use X- headers to send context as to why a grant has failed. Examples include API throttling, brute force lockouts, and OTP/two-factor authentication information.

Selfishly, I require this change so my application can be notified when the API has locked out an account due to suspicious activity via an X- header.

The decision to expose it as an option was chosen so backwards compatibility is maintained and keeps the addon simple for those who need not be concerned with complex backends.

* Add fastboot-dist to npmignore (#1015)

* Optionally send custom headers in authentication call (#1018)

Complex systems that offer Two Factor Authentication with their OAuth 2.0 implementation need to send additional context via the HTTP headers. This pattern has been observed in the wild by such systems such as GitHub. Because of the restrictions of OAuth 2.0 RFC, only headers can be used for additional context, not request/response bodies.

This could be seen as a counterpart to #1012, where using both features allow bi-directional context enabling 2FA, brute force lockouts, etc.

* [fastboot-compatibility] initial work

* [fastboot-compatbility] improve support

* [fastboot-compatibility] Use ember-cookies@0.0.7

ember-cookies 0.0.6

ember-cookies@0.0.7

* [fastboot-compatbility] fix ember-build-cli.js

* [fastboot-compatibility] fix route mixin transitions

* [fastboot-compatibility] Update `session-stores/cookie` with `typeof` guard (#1)

* [fastboot-compatiblity] fix tests

* Use apiHost config for dummy app.

better name for api host conf setting

fix dummy app API endpoints

* Helpful instructions for `npm run fastboot`

* Restore cookie session renewal

* Fix various rebase issues

* ember-cli-fasboot@1.0.0-beta.7

marcoow added a commit that referenced this pull request Sep 7, 2016

Fastboot Feature Branch (#1032)
* ignore store events while the session is busy (#965)

* 1.1.0-beta.5

* 1.1.0

* Check for resourceName in response in Devise Authenticator

* change cookie default key names to be rfc2616 compliant (#978)

fixes #977

* Test for session service data being set with Ember.set (#972)

* code/docs cleanup

* Add tokenRefreshOffset property to OAuth2PasswordGrantAuthenticator (#840)

tokenRefreshOffset determines the offset seconds before the token
expiration to refresh the token. This is randomized so as to reduce
race conditions between multiple tabs from refreshing at the same time.

This is configurable because in some cases, the offset randomization
needs to be increased to decrease the probability of the above mentioned
race conditions.

Once more case would be in slow internet connections, you make a call to
refresh the token but the server doesn't process it in time (or receive
it in time), the server will check and the token that you sent up is now
expired so the refresh will fail.

* cleanup transition usage in authenticated and unauthenticated route mixins (#992)

no issue
- fixes potential test timing issue
- removes unecessary abort call

* [BUGFIX] Remove Ember.Logger (#993)

Ember.Logger is not substituted by noops in production.

More info in emberjs/guides#1467

* [WIP] Validate server responses in authenticators (#957)

* Validate response data in devise authenticator

* Validate response data in OAuth2 authenticator

* Add tests for oauth2 data validations

* Add tests for devise data validations

* Remove unncessary validations

* Refactor 'restore' in devise authenticator

* Fix test timeout errors

* Minor cleanup

* Consider resource name when validating response

* Refactor devise authenticator _validate method

* update dependencies (#1004)

This updates Ember, Ember Data, Ember CLI etc. to the latest
versions. This also fixes a lot of JSCS warnings that were introduced
by the latest version of ember-suave.

* Use the term "squash" when referring to collapsing commits into one (#1011)

That's consistent with the term used in git-rebase and with the general public.

* Add rejectWithXhr to optionally reject with XHR vs response body (#1012)

Allows ember apps using ember-simple-auth to receive the whole XHR object if the backend fails, instead of the response body, if they so choose.

In the case of OAuth 2.0 backends, it's been a pattern in the wild to use X- headers to send context as to why a grant has failed. Examples include API throttling, brute force lockouts, and OTP/two-factor authentication information.

Selfishly, I require this change so my application can be notified when the API has locked out an account due to suspicious activity via an X- header.

The decision to expose it as an option was chosen so backwards compatibility is maintained and keeps the addon simple for those who need not be concerned with complex backends.

* Add fastboot-dist to npmignore (#1015)

* Optionally send custom headers in authentication call (#1018)

Complex systems that offer Two Factor Authentication with their OAuth 2.0 implementation need to send additional context via the HTTP headers. This pattern has been observed in the wild by such systems such as GitHub. Because of the restrictions of OAuth 2.0 RFC, only headers can be used for additional context, not request/response bodies.

This could be seen as a counterpart to #1012, where using both features allow bi-directional context enabling 2FA, brute force lockouts, etc.

* [fastboot-compatibility] initial work

* [fastboot-compatbility] improve support

* [fastboot-compatibility] Use ember-cookies@0.0.7

ember-cookies 0.0.6

ember-cookies@0.0.7

* [fastboot-compatbility] fix ember-build-cli.js

* [fastboot-compatibility] fix route mixin transitions

* [fastboot-compatibility] Update `session-stores/cookie` with `typeof` guard (#1)

* [fastboot-compatiblity] fix tests

* Use apiHost config for dummy app.

better name for api host conf setting

fix dummy app API endpoints

* Helpful instructions for `npm run fastboot`

* Restore cookie session renewal

* Fix various rebase issues

* ember-cli-fasboot@1.0.0-beta.7

bakerac4 added a commit to bakerac4/ember-simple-auth that referenced this pull request Sep 8, 2016

Fastboot Feature Branch (simplabs#1032)
* ignore store events while the session is busy (simplabs#965)

* 1.1.0-beta.5

* 1.1.0

* Check for resourceName in response in Devise Authenticator

* change cookie default key names to be rfc2616 compliant (simplabs#978)

fixes simplabs#977

* Test for session service data being set with Ember.set (simplabs#972)

* code/docs cleanup

* Add tokenRefreshOffset property to OAuth2PasswordGrantAuthenticator (simplabs#840)

tokenRefreshOffset determines the offset seconds before the token
expiration to refresh the token. This is randomized so as to reduce
race conditions between multiple tabs from refreshing at the same time.

This is configurable because in some cases, the offset randomization
needs to be increased to decrease the probability of the above mentioned
race conditions.

Once more case would be in slow internet connections, you make a call to
refresh the token but the server doesn't process it in time (or receive
it in time), the server will check and the token that you sent up is now
expired so the refresh will fail.

* cleanup transition usage in authenticated and unauthenticated route mixins (simplabs#992)

no issue
- fixes potential test timing issue
- removes unecessary abort call

* [BUGFIX] Remove Ember.Logger (simplabs#993)

Ember.Logger is not substituted by noops in production.

More info in emberjs/guides#1467

* [WIP] Validate server responses in authenticators (simplabs#957)

* Validate response data in devise authenticator

* Validate response data in OAuth2 authenticator

* Add tests for oauth2 data validations

* Add tests for devise data validations

* Remove unncessary validations

* Refactor 'restore' in devise authenticator

* Fix test timeout errors

* Minor cleanup

* Consider resource name when validating response

* Refactor devise authenticator _validate method

* update dependencies (simplabs#1004)

This updates Ember, Ember Data, Ember CLI etc. to the latest
versions. This also fixes a lot of JSCS warnings that were introduced
by the latest version of ember-suave.

* Use the term "squash" when referring to collapsing commits into one (simplabs#1011)

That's consistent with the term used in git-rebase and with the general public.

* Add rejectWithXhr to optionally reject with XHR vs response body (simplabs#1012)

Allows ember apps using ember-simple-auth to receive the whole XHR object if the backend fails, instead of the response body, if they so choose.

In the case of OAuth 2.0 backends, it's been a pattern in the wild to use X- headers to send context as to why a grant has failed. Examples include API throttling, brute force lockouts, and OTP/two-factor authentication information.

Selfishly, I require this change so my application can be notified when the API has locked out an account due to suspicious activity via an X- header.

The decision to expose it as an option was chosen so backwards compatibility is maintained and keeps the addon simple for those who need not be concerned with complex backends.

* Add fastboot-dist to npmignore (simplabs#1015)

* Optionally send custom headers in authentication call (simplabs#1018)

Complex systems that offer Two Factor Authentication with their OAuth 2.0 implementation need to send additional context via the HTTP headers. This pattern has been observed in the wild by such systems such as GitHub. Because of the restrictions of OAuth 2.0 RFC, only headers can be used for additional context, not request/response bodies.

This could be seen as a counterpart to simplabs#1012, where using both features allow bi-directional context enabling 2FA, brute force lockouts, etc.

* [fastboot-compatibility] initial work

* [fastboot-compatbility] improve support

* [fastboot-compatibility] Use ember-cookies@0.0.7

ember-cookies 0.0.6

ember-cookies@0.0.7

* [fastboot-compatbility] fix ember-build-cli.js

* [fastboot-compatibility] fix route mixin transitions

* [fastboot-compatibility] Update `session-stores/cookie` with `typeof` guard (simplabs#1)

* [fastboot-compatiblity] fix tests

* Use apiHost config for dummy app.

better name for api host conf setting

fix dummy app API endpoints

* Helpful instructions for `npm run fastboot`

* Restore cookie session renewal

* Fix various rebase issues

* ember-cli-fasboot@1.0.0-beta.7

bakerac4 added a commit to bakerac4/ember-simple-auth that referenced this pull request Sep 8, 2016

Fastboot Feature Branch (simplabs#1032)
* ignore store events while the session is busy (simplabs#965)

* 1.1.0-beta.5

* 1.1.0

* Check for resourceName in response in Devise Authenticator

* change cookie default key names to be rfc2616 compliant (simplabs#978)

fixes simplabs#977

* Test for session service data being set with Ember.set (simplabs#972)

* code/docs cleanup

* Add tokenRefreshOffset property to OAuth2PasswordGrantAuthenticator (simplabs#840)

tokenRefreshOffset determines the offset seconds before the token
expiration to refresh the token. This is randomized so as to reduce
race conditions between multiple tabs from refreshing at the same time.

This is configurable because in some cases, the offset randomization
needs to be increased to decrease the probability of the above mentioned
race conditions.

Once more case would be in slow internet connections, you make a call to
refresh the token but the server doesn't process it in time (or receive
it in time), the server will check and the token that you sent up is now
expired so the refresh will fail.

* cleanup transition usage in authenticated and unauthenticated route mixins (simplabs#992)

no issue
- fixes potential test timing issue
- removes unecessary abort call

* [BUGFIX] Remove Ember.Logger (simplabs#993)

Ember.Logger is not substituted by noops in production.

More info in emberjs/guides#1467

* [WIP] Validate server responses in authenticators (simplabs#957)

* Validate response data in devise authenticator

* Validate response data in OAuth2 authenticator

* Add tests for oauth2 data validations

* Add tests for devise data validations

* Remove unncessary validations

* Refactor 'restore' in devise authenticator

* Fix test timeout errors

* Minor cleanup

* Consider resource name when validating response

* Refactor devise authenticator _validate method

* update dependencies (simplabs#1004)

This updates Ember, Ember Data, Ember CLI etc. to the latest
versions. This also fixes a lot of JSCS warnings that were introduced
by the latest version of ember-suave.

* Use the term "squash" when referring to collapsing commits into one (simplabs#1011)

That's consistent with the term used in git-rebase and with the general public.

* Add rejectWithXhr to optionally reject with XHR vs response body (simplabs#1012)

Allows ember apps using ember-simple-auth to receive the whole XHR object if the backend fails, instead of the response body, if they so choose.

In the case of OAuth 2.0 backends, it's been a pattern in the wild to use X- headers to send context as to why a grant has failed. Examples include API throttling, brute force lockouts, and OTP/two-factor authentication information.

Selfishly, I require this change so my application can be notified when the API has locked out an account due to suspicious activity via an X- header.

The decision to expose it as an option was chosen so backwards compatibility is maintained and keeps the addon simple for those who need not be concerned with complex backends.

* Add fastboot-dist to npmignore (simplabs#1015)

* Optionally send custom headers in authentication call (simplabs#1018)

Complex systems that offer Two Factor Authentication with their OAuth 2.0 implementation need to send additional context via the HTTP headers. This pattern has been observed in the wild by such systems such as GitHub. Because of the restrictions of OAuth 2.0 RFC, only headers can be used for additional context, not request/response bodies.

This could be seen as a counterpart to simplabs#1012, where using both features allow bi-directional context enabling 2FA, brute force lockouts, etc.

* [fastboot-compatibility] initial work

* [fastboot-compatbility] improve support

* [fastboot-compatibility] Use ember-cookies@0.0.7

ember-cookies 0.0.6

ember-cookies@0.0.7

* [fastboot-compatbility] fix ember-build-cli.js

* [fastboot-compatibility] fix route mixin transitions

* [fastboot-compatibility] Update `session-stores/cookie` with `typeof` guard (simplabs#1)

* [fastboot-compatiblity] fix tests

* Use apiHost config for dummy app.

better name for api host conf setting

fix dummy app API endpoints

* Helpful instructions for `npm run fastboot`

* Restore cookie session renewal

* Fix various rebase issues

* ember-cli-fasboot@1.0.0-beta.7

marcoow added a commit that referenced this pull request Dec 6, 2016

FastBoot Compatibility (#1035)
* DRAFT - Fastboot compatibility

* improve fastboot support

* add FastBoot info to README

* fix tests

* better name for api host conf setting

* WIP: fixing tests

* fix tests

* Use version of ember-cookies with fix for fasboot

* ember-cookies 0.0.6

* fix config for fastboot

* never abort current transition in FastBoot

* don't abort transitions in FastBoot

* Fastboot Feature Branch (#1032)

* ignore store events while the session is busy (#965)

* 1.1.0-beta.5

* 1.1.0

* Check for resourceName in response in Devise Authenticator

* change cookie default key names to be rfc2616 compliant (#978)

fixes #977

* Test for session service data being set with Ember.set (#972)

* code/docs cleanup

* Add tokenRefreshOffset property to OAuth2PasswordGrantAuthenticator (#840)

tokenRefreshOffset determines the offset seconds before the token
expiration to refresh the token. This is randomized so as to reduce
race conditions between multiple tabs from refreshing at the same time.

This is configurable because in some cases, the offset randomization
needs to be increased to decrease the probability of the above mentioned
race conditions.

Once more case would be in slow internet connections, you make a call to
refresh the token but the server doesn't process it in time (or receive
it in time), the server will check and the token that you sent up is now
expired so the refresh will fail.

* cleanup transition usage in authenticated and unauthenticated route mixins (#992)

no issue
- fixes potential test timing issue
- removes unecessary abort call

* [BUGFIX] Remove Ember.Logger (#993)

Ember.Logger is not substituted by noops in production.

More info in emberjs/guides#1467

* [WIP] Validate server responses in authenticators (#957)

* Validate response data in devise authenticator

* Validate response data in OAuth2 authenticator

* Add tests for oauth2 data validations

* Add tests for devise data validations

* Remove unncessary validations

* Refactor 'restore' in devise authenticator

* Fix test timeout errors

* Minor cleanup

* Consider resource name when validating response

* Refactor devise authenticator _validate method

* update dependencies (#1004)

This updates Ember, Ember Data, Ember CLI etc. to the latest
versions. This also fixes a lot of JSCS warnings that were introduced
by the latest version of ember-suave.

* Use the term "squash" when referring to collapsing commits into one (#1011)

That's consistent with the term used in git-rebase and with the general public.

* Add rejectWithXhr to optionally reject with XHR vs response body (#1012)

Allows ember apps using ember-simple-auth to receive the whole XHR object if the backend fails, instead of the response body, if they so choose.

In the case of OAuth 2.0 backends, it's been a pattern in the wild to use X- headers to send context as to why a grant has failed. Examples include API throttling, brute force lockouts, and OTP/two-factor authentication information.

Selfishly, I require this change so my application can be notified when the API has locked out an account due to suspicious activity via an X- header.

The decision to expose it as an option was chosen so backwards compatibility is maintained and keeps the addon simple for those who need not be concerned with complex backends.

* Add fastboot-dist to npmignore (#1015)

* Optionally send custom headers in authentication call (#1018)

Complex systems that offer Two Factor Authentication with their OAuth 2.0 implementation need to send additional context via the HTTP headers. This pattern has been observed in the wild by such systems such as GitHub. Because of the restrictions of OAuth 2.0 RFC, only headers can be used for additional context, not request/response bodies.

This could be seen as a counterpart to #1012, where using both features allow bi-directional context enabling 2FA, brute force lockouts, etc.

* [fastboot-compatibility] initial work

* [fastboot-compatbility] improve support

* [fastboot-compatibility] Use ember-cookies@0.0.7

ember-cookies 0.0.6

ember-cookies@0.0.7

* [fastboot-compatbility] fix ember-build-cli.js

* [fastboot-compatibility] fix route mixin transitions

* [fastboot-compatibility] Update `session-stores/cookie` with `typeof` guard (#1)

* [fastboot-compatiblity] fix tests

* Use apiHost config for dummy app.

better name for api host conf setting

fix dummy app API endpoints

* Helpful instructions for `npm run fastboot`

* Restore cookie session renewal

* Fix various rebase issues

* ember-cli-fasboot@1.0.0-beta.7

* Fix tests for fastboot feature branch (#1034)

* fix my messed up rebase 😳

* fix cookie store

* [Fastboot] Remove inject of cookies in initializer; Bump ember-cookies; Add fastboot host whitelist (#1039)

* Add fastboot host whitelist

* Bump ember-cookies to make dummy app work

* Remove inject of cookies in initializers

* [Fastboot] Integration testing for fastboot (#1045)

* Add session register back

* Create a fastboot test app and create basic tests against fastboot.

* fix bad merge 😞

* I suck at merging 😱

* we might need to cleanup for the node tests…

* run both node test and FastBoot node test

* fix node tests

* increase timeout for fastboot node tests

* Update OAuth2PasswordGrant Authenticator to use Fetch (#1066)

* Using ember-network fetch for the oauth2 password grand authenticator

* Fixing unit tests for adding fetch to ember simple auth

* Changing naming of rejectWithRequest to rejectWithResponse

* Making rejectWithXhr a deprecatingAlias and adding import-polyfill to the node-tests app

* docs fixes

* don't bind to localStorage events in FastBoot

* fix test

* don't use window.location in fastboot

* update docs for fastboot

* use ember-network in devise authenticator

* fix tests

* rename fastboot app fixture

* rename fastboot test

* WIP: FastBoot regression test

* WIP: FastBoot regression test

* fix adaptive store for fastboot

* Merge branch 'master' into fastboot (#1098)

* Merge branch 'master' into fastboot

* Remove unneeded test

* Refactor to use ember-cookies clear()

* Try fix for 1.12

* Cleanup

* Cookie store `_secureCookies`: use correct protocol property in FastBoot mode (#1104)

* Merge latest master into fastboot (#1110)

* Update managing-current-user.md (#1068)

Avoid making a current user request if not authenticated

* Add explanatory comment to application route (#1069)

The setup-session-restoration initializer needs the application route to be explicitly defined in the consuming app, so simple auth must ship with this file in case the consuming app hasn't defined their own. However, if the consuming app has another addon that also provides an application route via it's app folder, simple auth may override that addon's file with this one, depending on the load order.

This is easily fixed by specifying an explicit load order (i.e. `after: 'ember-simple-auth'`). However, because the contents of this file are completely generic, and Ember's build process merges this file into the app folder without retaining source information, it's difficult to know from the consuming app's perspective that simple-auth is the addon providing this generic file (and therefore the `after` option needs to specify "ember-simple-auth").

This adds an explanatory comment, hopefully making it a bit clearer in case anyone is trying to figure out where this empty application route file is coming from.

* Cookie store rewrite (#1056)

* Persist to cookie when relevant attributes change

* Refactor cookie properties on adaptive store

* Fix cookie store getters and setters

* Fix adaptive store test

* Remove unused code

* Fix cookie properties on adaptive store

* Change cookie properties to adaptive store

* Fix cookie setters

* Fix jshint errors

* Remove unused code

* Wrap `rewriteCookie` in Ember.run.scheduleOnce

* Remove extra run.scheduleOnce

* Remove unnecessary jshint ignores

* Minor cleanup

* Fix cookie domain test

* Add tests for rewrite behavior

* Save WIP on shared cookie behavior

* fix cookie store rewrite behavior tests

* Small fixes (#1047)

* Fix jshint error

* Allow cookie to write blank values on clear

* Restore previous cookieDomain test

* Persist value in test so cookie will write

* Fix cookie domain test

* simplify AdaptiveStore code

* simplify cooke store code

* use CPs consistently internally

* code cleanup

* handle changes of cookie name correctly

* no need to clear before rewrite

* clear old expiration cookie as well

* Include path when deleting cookie (#1067)

* Refactor cookie string (#1074)

* Include path when deleting cookie

* Add a cookie string method

* Should `resolve` after fetching user. (#1077)

* Should `resolve` after fetching user.

Else the promise remains unresolved.

* Remove return as suggested in the review

* Remove yet another return as suggested

* Update "ember-cli-mocha" to v0.12.0 (#1105)

* Update "ember-cli-mocha" to v0.12.0

* tests: Import it() from "mocha"

* tests: Use new testing API in ember-mocha

* Fix OAuth2 authenticator tokenRefreshOffset (#1106)

* Fix OAuth2 authenticator tokenRefreshOffset

* Fix lint mistake

* Ensure correct root url handling (#1070)

* set rootURL on router correctly

* document readonly correctly

* use rootURL if present

* Fix typo (#1109)

* cleanup

* remove unnecessary injection

* remove unnecessary property

* fix dependency versions

* use cookie session store in dummy app

olleolleolle added a commit to olleolleolle/ember-simple-auth that referenced this pull request Dec 7, 2016

FastBoot Compatibility (simplabs#1035)
* DRAFT - Fastboot compatibility

* improve fastboot support

* add FastBoot info to README

* fix tests

* better name for api host conf setting

* WIP: fixing tests

* fix tests

* Use version of ember-cookies with fix for fasboot

* ember-cookies 0.0.6

* fix config for fastboot

* never abort current transition in FastBoot

* don't abort transitions in FastBoot

* Fastboot Feature Branch (simplabs#1032)

* ignore store events while the session is busy (simplabs#965)

* 1.1.0-beta.5

* 1.1.0

* Check for resourceName in response in Devise Authenticator

* change cookie default key names to be rfc2616 compliant (simplabs#978)

fixes simplabs#977

* Test for session service data being set with Ember.set (simplabs#972)

* code/docs cleanup

* Add tokenRefreshOffset property to OAuth2PasswordGrantAuthenticator (simplabs#840)

tokenRefreshOffset determines the offset seconds before the token
expiration to refresh the token. This is randomized so as to reduce
race conditions between multiple tabs from refreshing at the same time.

This is configurable because in some cases, the offset randomization
needs to be increased to decrease the probability of the above mentioned
race conditions.

Once more case would be in slow internet connections, you make a call to
refresh the token but the server doesn't process it in time (or receive
it in time), the server will check and the token that you sent up is now
expired so the refresh will fail.

* cleanup transition usage in authenticated and unauthenticated route mixins (simplabs#992)

no issue
- fixes potential test timing issue
- removes unecessary abort call

* [BUGFIX] Remove Ember.Logger (simplabs#993)

Ember.Logger is not substituted by noops in production.

More info in emberjs/guides#1467

* [WIP] Validate server responses in authenticators (simplabs#957)

* Validate response data in devise authenticator

* Validate response data in OAuth2 authenticator

* Add tests for oauth2 data validations

* Add tests for devise data validations

* Remove unncessary validations

* Refactor 'restore' in devise authenticator

* Fix test timeout errors

* Minor cleanup

* Consider resource name when validating response

* Refactor devise authenticator _validate method

* update dependencies (simplabs#1004)

This updates Ember, Ember Data, Ember CLI etc. to the latest
versions. This also fixes a lot of JSCS warnings that were introduced
by the latest version of ember-suave.

* Use the term "squash" when referring to collapsing commits into one (simplabs#1011)

That's consistent with the term used in git-rebase and with the general public.

* Add rejectWithXhr to optionally reject with XHR vs response body (simplabs#1012)

Allows ember apps using ember-simple-auth to receive the whole XHR object if the backend fails, instead of the response body, if they so choose.

In the case of OAuth 2.0 backends, it's been a pattern in the wild to use X- headers to send context as to why a grant has failed. Examples include API throttling, brute force lockouts, and OTP/two-factor authentication information.

Selfishly, I require this change so my application can be notified when the API has locked out an account due to suspicious activity via an X- header.

The decision to expose it as an option was chosen so backwards compatibility is maintained and keeps the addon simple for those who need not be concerned with complex backends.

* Add fastboot-dist to npmignore (simplabs#1015)

* Optionally send custom headers in authentication call (simplabs#1018)

Complex systems that offer Two Factor Authentication with their OAuth 2.0 implementation need to send additional context via the HTTP headers. This pattern has been observed in the wild by such systems such as GitHub. Because of the restrictions of OAuth 2.0 RFC, only headers can be used for additional context, not request/response bodies.

This could be seen as a counterpart to simplabs#1012, where using both features allow bi-directional context enabling 2FA, brute force lockouts, etc.

* [fastboot-compatibility] initial work

* [fastboot-compatbility] improve support

* [fastboot-compatibility] Use ember-cookies@0.0.7

ember-cookies 0.0.6

ember-cookies@0.0.7

* [fastboot-compatbility] fix ember-build-cli.js

* [fastboot-compatibility] fix route mixin transitions

* [fastboot-compatibility] Update `session-stores/cookie` with `typeof` guard (#1)

* [fastboot-compatiblity] fix tests

* Use apiHost config for dummy app.

better name for api host conf setting

fix dummy app API endpoints

* Helpful instructions for `npm run fastboot`

* Restore cookie session renewal

* Fix various rebase issues

* ember-cli-fasboot@1.0.0-beta.7

* Fix tests for fastboot feature branch (simplabs#1034)

* fix my messed up rebase 😳

* fix cookie store

* [Fastboot] Remove inject of cookies in initializer; Bump ember-cookies; Add fastboot host whitelist (simplabs#1039)

* Add fastboot host whitelist

* Bump ember-cookies to make dummy app work

* Remove inject of cookies in initializers

* [Fastboot] Integration testing for fastboot (simplabs#1045)

* Add session register back

* Create a fastboot test app and create basic tests against fastboot.

* fix bad merge 😞

* I suck at merging 😱

* we might need to cleanup for the node tests…

* run both node test and FastBoot node test

* fix node tests

* increase timeout for fastboot node tests

* Update OAuth2PasswordGrant Authenticator to use Fetch (simplabs#1066)

* Using ember-network fetch for the oauth2 password grand authenticator

* Fixing unit tests for adding fetch to ember simple auth

* Changing naming of rejectWithRequest to rejectWithResponse

* Making rejectWithXhr a deprecatingAlias and adding import-polyfill to the node-tests app

* docs fixes

* don't bind to localStorage events in FastBoot

* fix test

* don't use window.location in fastboot

* update docs for fastboot

* use ember-network in devise authenticator

* fix tests

* rename fastboot app fixture

* rename fastboot test

* WIP: FastBoot regression test

* WIP: FastBoot regression test

* fix adaptive store for fastboot

* Merge branch 'master' into fastboot (simplabs#1098)

* Merge branch 'master' into fastboot

* Remove unneeded test

* Refactor to use ember-cookies clear()

* Try fix for 1.12

* Cleanup

* Cookie store `_secureCookies`: use correct protocol property in FastBoot mode (simplabs#1104)

* Merge latest master into fastboot (simplabs#1110)

* Update managing-current-user.md (simplabs#1068)

Avoid making a current user request if not authenticated

* Add explanatory comment to application route (simplabs#1069)

The setup-session-restoration initializer needs the application route to be explicitly defined in the consuming app, so simple auth must ship with this file in case the consuming app hasn't defined their own. However, if the consuming app has another addon that also provides an application route via it's app folder, simple auth may override that addon's file with this one, depending on the load order.

This is easily fixed by specifying an explicit load order (i.e. `after: 'ember-simple-auth'`). However, because the contents of this file are completely generic, and Ember's build process merges this file into the app folder without retaining source information, it's difficult to know from the consuming app's perspective that simple-auth is the addon providing this generic file (and therefore the `after` option needs to specify "ember-simple-auth").

This adds an explanatory comment, hopefully making it a bit clearer in case anyone is trying to figure out where this empty application route file is coming from.

* Cookie store rewrite (simplabs#1056)

* Persist to cookie when relevant attributes change

* Refactor cookie properties on adaptive store

* Fix cookie store getters and setters

* Fix adaptive store test

* Remove unused code

* Fix cookie properties on adaptive store

* Change cookie properties to adaptive store

* Fix cookie setters

* Fix jshint errors

* Remove unused code

* Wrap `rewriteCookie` in Ember.run.scheduleOnce

* Remove extra run.scheduleOnce

* Remove unnecessary jshint ignores

* Minor cleanup

* Fix cookie domain test

* Add tests for rewrite behavior

* Save WIP on shared cookie behavior

* fix cookie store rewrite behavior tests

* Small fixes (simplabs#1047)

* Fix jshint error

* Allow cookie to write blank values on clear

* Restore previous cookieDomain test

* Persist value in test so cookie will write

* Fix cookie domain test

* simplify AdaptiveStore code

* simplify cooke store code

* use CPs consistently internally

* code cleanup

* handle changes of cookie name correctly

* no need to clear before rewrite

* clear old expiration cookie as well

* Include path when deleting cookie (simplabs#1067)

* Refactor cookie string (simplabs#1074)

* Include path when deleting cookie

* Add a cookie string method

* Should `resolve` after fetching user. (simplabs#1077)

* Should `resolve` after fetching user.

Else the promise remains unresolved.

* Remove return as suggested in the review

* Remove yet another return as suggested

* Update "ember-cli-mocha" to v0.12.0 (simplabs#1105)

* Update "ember-cli-mocha" to v0.12.0

* tests: Import it() from "mocha"

* tests: Use new testing API in ember-mocha

* Fix OAuth2 authenticator tokenRefreshOffset (simplabs#1106)

* Fix OAuth2 authenticator tokenRefreshOffset

* Fix lint mistake

* Ensure correct root url handling (simplabs#1070)

* set rootURL on router correctly

* document readonly correctly

* use rootURL if present

* Fix typo (simplabs#1109)

* cleanup

* remove unnecessary injection

* remove unnecessary property

* fix dependency versions

* use cookie session store in dummy app
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment