Default keys for cookies are not RFC standard compliant #977
Labels
Comments
|
Hm, good point. Thought I checked when I decided on these names… Want to submit a PR? |
|
@marcoow Can do, haven't thought about how to name them instead yet. Replace with |
|
Yeah, I'd say replacing |
|
Yes true, except for those who overwrote the default key name.
|
wzrdtales
added a commit
to wzrdtales/ember-simple-auth
that referenced
this issue
May 13, 2016
|
I guess you will also need to announce this as a probably breaking change, as the users of |
|
No, this doesn't change any API. The cookie is not supposed to be used directly be the backend - it's internals and name might be changed any time as it is considered private API in its entirety. The only side effect of this change is that all users will be logged out when deploying this but I don't consider that a breaking change really as that probably happens for other reasons from time to time anyway |
marcoow
pushed a commit
that referenced
this issue
May 13, 2016
arjansingh
pushed a commit
to arjansingh/ember-simple-auth
that referenced
this issue
Jul 27, 2016
marcoow
pushed a commit
that referenced
this issue
Jul 28, 2016
* 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
pushed a commit
that referenced
this issue
Jul 28, 2016
* 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
pushed a commit
that referenced
this issue
Sep 7, 2016
* 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
pushed a commit
to bakerac4/ember-simple-auth
that referenced
this issue
Sep 8, 2016
* ignore store events while the session is busy (mainmatter#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 (mainmatter#978) fixes mainmatter#977 * Test for session service data being set with Ember.set (mainmatter#972) * code/docs cleanup * Add tokenRefreshOffset property to OAuth2PasswordGrantAuthenticator (mainmatter#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 (mainmatter#992) no issue - fixes potential test timing issue - removes unecessary abort call * [BUGFIX] Remove Ember.Logger (mainmatter#993) Ember.Logger is not substituted by noops in production. More info in emberjs/guides#1467 * [WIP] Validate server responses in authenticators (mainmatter#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 (mainmatter#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 (mainmatter#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 (mainmatter#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 (mainmatter#1015) * Optionally send custom headers in authentication call (mainmatter#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 mainmatter#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 (mainmatter#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
pushed a commit
to bakerac4/ember-simple-auth
that referenced
this issue
Sep 8, 2016
* ignore store events while the session is busy (mainmatter#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 (mainmatter#978) fixes mainmatter#977 * Test for session service data being set with Ember.set (mainmatter#972) * code/docs cleanup * Add tokenRefreshOffset property to OAuth2PasswordGrantAuthenticator (mainmatter#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 (mainmatter#992) no issue - fixes potential test timing issue - removes unecessary abort call * [BUGFIX] Remove Ember.Logger (mainmatter#993) Ember.Logger is not substituted by noops in production. More info in emberjs/guides#1467 * [WIP] Validate server responses in authenticators (mainmatter#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 (mainmatter#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 (mainmatter#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 (mainmatter#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 (mainmatter#1015) * Optionally send custom headers in authentication call (mainmatter#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 mainmatter#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 (mainmatter#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 issue
Dec 6, 2016
* 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
pushed a commit
to olleolleolle/ember-simple-auth
that referenced
this issue
Dec 7, 2016
* 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 (mainmatter#1032) * ignore store events while the session is busy (mainmatter#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 (mainmatter#978) fixes mainmatter#977 * Test for session service data being set with Ember.set (mainmatter#972) * code/docs cleanup * Add tokenRefreshOffset property to OAuth2PasswordGrantAuthenticator (mainmatter#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 (mainmatter#992) no issue - fixes potential test timing issue - removes unecessary abort call * [BUGFIX] Remove Ember.Logger (mainmatter#993) Ember.Logger is not substituted by noops in production. More info in emberjs/guides#1467 * [WIP] Validate server responses in authenticators (mainmatter#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 (mainmatter#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 (mainmatter#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 (mainmatter#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 (mainmatter#1015) * Optionally send custom headers in authentication call (mainmatter#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 mainmatter#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 (mainmatter#1034) * fix my messed up rebase 😳 * fix cookie store * [Fastboot] Remove inject of cookies in initializer; Bump ember-cookies; Add fastboot host whitelist (mainmatter#1039) * Add fastboot host whitelist * Bump ember-cookies to make dummy app work * Remove inject of cookies in initializers * [Fastboot] Integration testing for fastboot (mainmatter#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 (mainmatter#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 (mainmatter#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 (mainmatter#1104) * Merge latest master into fastboot (mainmatter#1110) * Update managing-current-user.md (mainmatter#1068) Avoid making a current user request if not authenticated * Add explanatory comment to application route (mainmatter#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 (mainmatter#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 (mainmatter#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 (mainmatter#1067) * Refactor cookie string (mainmatter#1074) * Include path when deleting cookie * Add a cookie string method * Should `resolve` after fetching user. (mainmatter#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 (mainmatter#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 (mainmatter#1106) * Fix OAuth2 authenticator tokenRefreshOffset * Fix lint mistake * Ensure correct root url handling (mainmatter#1070) * set rootURL on router correctly * document readonly correctly * use rootURL if present * Fix typo (mainmatter#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
The default key names of this plugin are
ember_simple_auth:sessionandember_simple_auth:session:expiration_timethose are not standard compliant b/c of the colon in them.Have a read of this gist that gives a good summary: https://gist.github.com/jeremiahlee/ff7dfb60572211dce306
This causes problems as soon as you use cookies and your backend is itself standard compliant and validates cookies or also if the backend validates the headers, one example would be
hapi.jsyou will be denied to access those applications with an error likeAnd the behavior of
hapi.jsis not wrong, they do deny the request right, but ember-simple-auth's default key names are wrong, so I would suggest to change those.The text was updated successfully, but these errors were encountered: