🌱 Make response_type configurable #153
Conversation
packages/okta-vue/src/Auth.spec.js
Outdated
| redirect_uri: '3', | ||
| response_type: 'a b' | ||
| }) | ||
| expect(localVue.prototype.$auth).toBeDefined() |
There was a problem hiding this comment.
We don't expose the configuration or the AuthJS object in Vue, so there is no good way to check this feat.
Instead, we're ensuring the object still will be created.
There was a problem hiding this comment.
Using mocking you can still test the desired side effect: that oktaAuth.token.getWithRedirect is called with the right values, given the input options given to the Auth plugin constructor. Since there is already a mock of the internal authJs instance in this test file, you can use jest.fn() to add a mock version of token.getWithRedirect() to it and then use the mock.calls property to see that it was called with the expected response_type
jmelberg-okta
force-pushed
the
jm-OKTA-157160-vue
branch
from
c38494c to
be58ab3
Compare
packages/okta-vue/src/Auth.spec.js
Outdated
| const mockCallValues = mockAuthJsInstance.token.getWithRedirect.mock.calls[0][0] | ||
| expect(mockCallValues.responseType).toEqual(expect.arrayContaining(['token'])) | ||
| expect(mockCallValues.scopes).toEqual(expect.arrayContaining(['foo', 'bar'])) | ||
| }) |
There was a problem hiding this comment.
👍 awesome! I think we should also add another test that asserts that response_type will default to ['id_token', 'token'] if not overridden by config, because this is a library decision that we are explicitly making.
Description
Allows the OAuth 2.0
response_typeto be configurable for implicit flows.Important:
codeisn't explicitly supported yet.Resolves: #109