D10: Re-vet Auth0 (drupal/auth0)

Created on 30 January 2024, 10 months ago
Updated 19 February 2024, 9 months ago

Problem/Motivation

Project URL: https://www.drupal.org/project/auth0 β†’

This module was previously vetted and determined obsolete due to not being PHP 8+ compatible. Snippet:

{
    "package": null,
    "note": "This module is not yet compatible with PHP 8 β€” see https://www.drupal.org/project/auth0/issues/3258312.",
    "replaces": {
        "name": "auth0"
    },
    "vetted": true
},

That issue is now closed and there is a beta release.

I was able to successfully install the module and enable it in a D10 environment, but we should vet this for D10 compatibility which will require setting up an account on Auth0 and following all the steps listed out here - https://www.drupal.org/docs/contributed-modules/saml-sp-single-sign-on-s... β†’ .

Steps to reproduce

n/a

Proposed resolution

n/a

Remaining tasks

  1. Install auth0 module on fresh D7 site
  2. Use acli to generate new D10 project
  3. Make sure auth0 is enabled
  4. Configure auth0 and make sure it functions in D10 env
  5. Consider migrating settings(?) these are (hopefully) stored in settings overrides since they are private, so a migration probably moot/overkill.
  6. Update recommendation in curated.json based on results

User interface changes

n/a

API changes

n/a

Data model changes

n/a

πŸ“Œ Task
Status

Fixed

Version

1.9

Component

Recommendations

Created by

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @dan612
  • πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

    What a great guide written here! β†’

    I followed it through and was successful in getting my Drupal 10 site set up with Auth0:

    Video here β†’ πŸ™‚

    I don't think it's worthwhile to try to migrate the standard LOGIN settings from Auth0 in D7 to D10. Best practice would also dictate these not even be stored in configuration, but rather set with an override.

    We could write a migration for some of the advanced settings though which might be helpful ( I opened this issue to address πŸ“Œ Create migration of advanced settings from Drupal 7 to Drupal 10 Active ). Should we wait for that issue to be completed before updating the recommendation? Or do you think that is a "nice to have " - as this module is going to require manual setup anyway.

    I updated this recommendation to be...something that might fit...but happy to reevaluate πŸ˜€

  • Merge request !263418183: Vet auth0 β†’ (Merged) created by dan612
  • Pipeline finished with Success
    10 months ago
    Total: 491s
    #85136
  • Pipeline finished with Success
    10 months ago
    Total: 546s
    #85137
  • Status changed to Needs review 10 months ago
  • πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine
  • Status changed to Needs work 10 months ago
  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    One small remark, then I'll merge!

  • πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

    But not migrating advanced settings which probably should be reassessed anyway … that does make sense. Can you clarify that in the note, please?

    I don't think I described what I was trying to do very well haha πŸ˜ƒ There are 2 aspects of settings for this module:

    Login Credentials:

    Advanced Settings

    The login credentials I don't think would be necessary to migrate.

    The advanced settings do contain some data which could prove beneficial to migrate over. For example auth0_role_mapping, contains a mapping of Auth0 role names to Drupal Roles, a la:
    s:19:"admin|administrator";

    Or the auth0_claim_mapping contains a mapping of Auth0 profile names to Drupal user field names:
    s:27:"given_name|field_first_name";

    It was these settings which I was thinking might be worthwhile to migrate over so users don't have to copy them manually. But probably a nice to have vs hard blocker.

    making me wonder why we'd consider this vetted if it's not

    I think i was considering it vetted because I was able to set it up and have a functioning D10 module (after manual setup) - so can confirm it works, but there is no (existing) automated way to get it 100% in place

  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    I think i was considering it vetted because I was able to set it up and have a functioning D10 module (after manual setup) - so can confirm it works, but there is no (existing) automated way to get it 100% in place.

    Yep, that's totally fine β€” there's a lot of gray between all the black and white :)

    All I was asking for is a clearer note 😊 Don't say "it's lacking X", say "X requires manual setup, because it needs manual re-evaluation" πŸ‘

  • πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

    All I was asking for is a clearer note 😊 Don't say "it's lacking X", say "X requires manual setup, because it needs manual re-evaluation" πŸ‘

    😁 got it -- updated the note in the issue fork MR.

  • Status changed to Needs review 10 months ago
  • πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine
  • Pipeline finished with Success
    10 months ago
    Total: 489s
    #86806
  • Issue was unassigned.
  • Status changed to RTBC 10 months ago
  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί
  • Pipeline finished with Skipped
    10 months ago
    #87762
  • Status changed to Fixed 10 months ago
  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024