WP-Auth0 V4

[glena]

Lets create small PRs (one for each change) for this release in a new branch (4.x.x-dev). This version will focus in P2 and no legacy features will be supported.

---

Priority

• [x] We should support HS and RS signed tokens. For RS we should be able to fetch the public key from the jwks.json endpoint.
• [ ] We should support both, hosted login page and embed lock (configurable in the settings page).
• [ ] For embed lock, it should use the oidcConformant flag and use the flow that posts the id_token to the backend (implicit flow)
• [ ] For hosted login page, we should support both, response type code and form_post
• [ ] We should support the following parameters as first class settings: audience, scope (configurable in the basic tab)

---

• [ ] Configuration wizard: it should use the new pipeline (without the /i path if available with auth0.auth0.com)
• [ ] The scopes requested during the configuration wizard should be enough to create a non interactive client and grant access to the required scopes for the management api RS.
• [ ] For offline flow it should request the client_id and secret and explain how to manually create it instead of asking for a token.
• [ ] We should change when it does api calls to fetch the api token through client credentials grant. It should store the token and the expires in attribute in order to know when it should fetch a new token (it should never decode the access token)

---

• [ ] We should start cleaning up some flows. WIth this changes we can start working on rewrite the LoginManager and the configuration wizard.

[mostekcm]

A couple of suggestions:

1) it might be nice to start building an e2e test suite. Something that uses selenium to walk through the flows. It would have to run against vagrantpress so might not be able to build it into CI, but it would help :).

2) I could create an extension for offline setup that would create the management API client with the right scopes. I did that for the deploy CLI. It is pretty simple. Then the instructions would just show them how to install that extension.

2)

[glena]

1. yes but not sure if really usefull. Also to run it in the CI, we need to use saucelabs and vagrantpress wont work for this. We need some hosted site (pantheon is an option, where we can push code via git). Anyway, starting with some unit tests might be more valuable (testing how we build lock options, testing the login handler, etc

2. good idea. At some point I started thinking about using an extension for the entire thing. It can ask you for the site url, it will ping it to get some info (name, etc) and set up everything in auth0. This way we get rid of the issues with custom routes and the web server url rewrites. It can end up exporting a json file that needs to be imported in the plugin (already has that feature).

[mostekcm]

Unit tests first is a good idea. The main idea with the e2e tests is that it will give us a way to test with new versions of Wordpress and woocommerce so we ensure we didn't get broken by them... I agree it would be a pain to get it into CI. So let's start with unit and go from there.

For extensions that could work too, and this first version could lay the groundwork. My only concern would be with versioning. The nice thing about most of the logic in the plugin is that it's been tested against that version of the plugin. On Thu, Feb 2, 2017 at 08:03 Germán Lena notifications@github.com wrote:

1.

yes but not sure if really usefull. Also to run it in the CI, we need to use saucelabs and vagrantpress wont work for this. We need some hosted site (pantheon is an option, where we can push code via git). Anyway, starting with some unit tests might be more valuable (testing how we build lock options, testing the login handler, etc 2.

good idea. At some point I started thinking about using an extension for the entire thing. It can ask you for the site url, it will ping it to get some info (name, etc) and set up everything in auth0. This way we get rid of the issues with custom routes and the web server url rewrites. It can end up exporting a json file that needs to be imported in the plugin (already has that feature).

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/auth0/wp-auth0/issues/282#issuecomment-276965030, or mute the thread https://github.com/notifications/unsubscribe-auth/ACheriU2TCjnjue4Cbm2Octcz22DslyZks5rYeHxgaJpZM4L1DOp .

-- Carlos Mostek

Customer Success Solution Architect cell: +1 612-247-6537 email: carlos.mostek@auth0.com https://www.auth0.com

[gjsman]

Any updates?

[joshcanhelp]

Configuration changes moved to #408.

Universal login page support is coming soon, will be released right after 3.6.0 so SSO users.

"We should support the following parameters as first class settings: audience, scope (configurable in the basic tab)" - Not sure if these should be settings or filters. Scope filter coming in 3.6.0 at least.

Initial configuration change, profile management, and general cleanup will be the focus of 4.0.0. Roadmap looks like:

• 3.6.0 - almost feature complete, currently being tested
• 3.6.1 - minor code quality and any 3.6.0 clean-up
• 3.7.0 - Universal login page for SSO
• 4.0.0 - Profile management and improved setup