Skip to content

Conversation

@metasean
Copy link

@metasean metasean commented Jul 9, 2019

This pull request adds support for Okta (specifically via "implicit flow").

@codecov
Copy link

codecov bot commented Jul 9, 2019

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (c2a8aee) to head (e48d592).
⚠️ Report is 798 commits behind head on dev.

Additional details and impacted files
@@ Coverage Diff @@ ## dev #402 +/- ## ========================================= Coverage 100.00% 100.00% ========================================= Files 1 1 Lines 2 2 ========================================= Hits 2 2 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
@rgylling
Copy link

Would be nice to have the ability to customize the okta url to utilize different dev modes.
ie https://${strategy.domain}.${strategy.oktaUrl}.com/oauth2/${serverId}/v1.
We use oktapreview.com

@metasean
Copy link
Author

@rgylling - That was a super-simple config to add in. Please let me know how it works for you. 😀

@rgylling
Copy link

@metasean Awesome thanks for the quick fix. I was editing your source code to get it working locally so this will be much better!

@runningrandall
Copy link

runningrandall commented Oct 22, 2019

Base branch conflicts have been resolved. Any chance we can get this merged?

@runningrandall
Copy link

Just following up on this.

@smisaacs
Copy link

smisaacs commented Jan 13, 2020

can this get merged?

@jaypeeig
Copy link

interesting, I'm looking for this solution.. any chance this can be merged?

@@ -0,0 +1,75 @@
# Do not edit. File was generated by node-gyp's "configure" step
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we need this file?


2. Okta defaults to `/implicit/callback` instead of `callback`, so you _MUST_ ensure that you _EITHER_ have a corresponding callback component (i.e. `pages/implicit/callback.vue`) _OR_ that you change your Okta settings (Applications >> \<app\> >> General >> Logout redirect URIs).

3. These instructions use the `@nuxtjs/dotenv` module extensively. This module and approach isn't strictly necessary, but is *_highly_* recommended, particularly if you are going to be using different Okta domains or server ids across environments (e.g. for different stages of CI).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think highly recommended should have a reason and IMO it is not recommended to use a .env file, especially for CI/CD, flows but recommend using environment variables. Suggest to read The Twelve-Factor App

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imo its useful for local dev it keeps you env variables isolated per project and someone can transfer their .env file for quick dev setup and it is easy to add or remove env variables.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@noobling I would be happy to discuss more but I think is out of the scope of this PR review and even if we finally end up recommended .env file, it should be module-wise not just for a specific provider that with the implicit flow doesn't even contain a server secret.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pi0 I agree it is out of scope of this PR and should be removed.

From my understanding using a .env file is using environment variables. https://cli.vuejs.org/guide/mode-and-env.html#environment-variables.

Using separate .env files per environment/mode and adding them to .gitignore seems to work well foor CI/CD. I'm absolutely open to other methods for configuration of single-page apps. (although out of scope of this PR)

### 1. Install dependencies
`npm install @nuxtjs/auth @nuxtjs/axios @nuxtjs/dotenv`

<details>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We cannot merge PR with this!


auth: {
redirect: {
callback: process.env.REDIRECT_CALLBACK_URI, // optional
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe as a demo we can simply put defaults and comments here? + As of implicit flow, I don't see any point obscuring configuration with a dotenv file by default unless there is a deployment requirement to have different values for prod which is out of scope of this intro example or can be mentioned in footer to use either environment fallback like '/' || process.env.OKTA_REDIRECT_CALLBACK_API or node config package or dotenv


## 4. Initialize your vuex store

Create an `index.js` file in your `store` directory. An empty `index.js` is perfectly acceptable for this purpose.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a part of module installement not provider. Can be simply a note about ensure having store dir :)

- Okta does *_NOT_* provide a default logout redirect, therefore it *_MUST_* be set or users will get an error on logout. This module provides a default logout redirect value of `/`.

- `auth.strategies.okta.url` is optional and defaults to `okta.com`.
-
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

extra line?

// Handle callbacks on page load
const redirected = await this._handleCallback()

// TODO: determine if it is necessary to pull user info on EACH and EVERY page request?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed it is. HTTP is stateless by nature! So for each SSR request, we need to either restore user from cookies (which implies transferring an object 2x per request) or fetching from remote.

@runningrandall
Copy link

Updated PR. Tests are passing now that I merge the right dev branch as opposed to master 🤦‍♂

@ldiebold
Copy link

Would it make more sense to wait until PKCE is implemented?
It seems sensible to start nudging people in that direction since there's less security holes.
https://oauth.net/2/grant-types/implicit/

The commit: #507

Is there any reason we shouldn't consider moving all default flows to PKCE where possible, once it's available?

@smisaacs
Copy link

smisaacs commented Apr 2, 2020

any progress on this merge?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

8 participants