thathoff / kirby-oauth Goto Github PK

Kirby 3.2 will add a custom login screen plugin type so we might rebuild the hackish solution for adding the Login-Button into the login screen.

This might also close #2.

I know, this plugin is currently meant to log in Oauth users into the Kirby panel. However, Kirby users can also be used to implement restricted pages (see https://getkirby.com/docs/cookbook/security/access-restriction) by creating a user group, that doesn't have access to the panel.

Therefore, it'd be great, if there was an optional config option for a redirect target (after succesful login) other than /panel, so it could be used to direct the user to some restricted page, e.g. /internalPage/someSubpage.

Are you open this? I might come up with a PR, if this is okay for you.

Hi Markus.
I really love your plugin, it works perfectly. Just one small thing :-)

I set 'onlyOauth' => true because I only want to allow users to login via oauth login screen. But there is one additional click necessary before I am redirected to the oauth login screen (See sreenshot!). Is there a way to skip this step and directly redirect to th login screen, because this is the only possibility to login anyway?

I configured the plugin like this:

c::set('blankogmbh.oauth', [
  'providers' => [
    'google' => [
      'class' => 'League\OAuth2\Client\Provider\Google',
      'clientId' => $googleClientId,
      'clientSecret' => $googleSecret
    ],
  ],
  'onlyExistingUsers' => true,
  'defaultRole' => 'blogger',
  'domainWhitelist' => ['domain.ch']
]);

When trying to authenticate with Google, I always got an error saying redirect_uri_mismatch while my redirect URL was correctly white listed in the Google Developers Console.

After investigating a bit, I found that in src/ProvidersManager.php line 22 to 24 the redirectUri is automatically set to $kirby->request()->url() when not defined; which for me results in http://domain.io/oauth.

Setting the redirectUri manually in the provider settings to http://liip.io/oauth/login/google fixes the issue.

I guess $kirby->request()->url() is not appropriate and should be completed with /login/{provider-name}, or am I missing something?

Kirby 3.2.3
kirby-oauth 1.0.0
league/oauth2-google 3.0.1

When logging in with Kirby 3.5 and the user has not been created yet it fails with “Please enter a valid password. Passwords must be at least 8 characters long.”

I just installed the plugin (Kirby 3.5.3 / no other plugins) and the OAuth buttons didn't show up.

On the plugins index.js:8 starting with if (url.indexOf(window.panel.url) === 0) { ... } the url.indexOf(window.panel.url) gives me back 5, so when i change that, the OAuth button shows up.
Just read on PR #12 that there is a similar problem, so maybe this helps for debugging.

Thanks for the plugin!

Edit:
Getting different results depending on the port?
"http://localhost:3000/panel/login" -> 5
"http://localhost:8000/panel/login" -> 0

The oauth-buttons do not show up in the login screen due to our workaround for circumventing a bug in overriding the login view.

We should drop the support for Kirby < 3.5.0 and remove the circumvention.

The plugin breaks with Kirby 3.6. because of the reworked components.

Hey there,

thanks for this lovely plugin. I'm trying to make it work with Nextcloud as the OAuth Provider (via the GenericProvider from PHPLeague). Unfortunately, in the Nextcloud OAuth implementation I need to set the redirect URL when I create the OAuth App within Nextcloud.

In the readme.md I did not find any documentation about the structure of the redirect URL, which needs to be used, so that the plugin can login the Kirby user correctly. By looking at the code I assumed it would be https://mykirby.com/oauth/myprovider/login, but this does not seem to work for me.

EDIT: Eventually, I figured out, that it's /oauth/login/myProvider. I still think it would be good, to have this in the readme.md.

Thanks,

The section “Configure Allowed Users” in readme is missing.

Hi,

I've set the Kirby configuration option for the panel slug:
'panel' => ['slug' => 'backend']

Unfortunately, the plugin redirects to /panel after the oAuth process, ignoring the custom slug setting.

Code Example:

Here's the relevant part of the plugin's code, class Controller:

private function goToPanel() {
    go("panel");
}

Expected Behavior:

The plugin should read the Kirby configuration setting for panel.slug and use that instead of hardcoding the /panel path.

Steps to Reproduce:

• Set panel.slug in Kirby configuration to a custom value, e.g., 'backend'.
• Perform an oAuth process that triggers the redirect to the panel.
• Observe that the plugin redirects to /panel instead of the custom slug.

Suggested Fix:

Modify the plugin to read the Kirby configuration setting for panel.slug and use that value for redirection.

Thank you for considering this enhancement.

The latest Kirby version 4.2.0 seems to have changed some things about the Login form. With the kirby-oauth plugin installed, you will only see the Oauth login. Kirbys native/default form inputs, are always hidden – no matter the onlyOauth setting.

Kirby seems to allow creating the first user programmatically even if installation is disabled. So we need to impersonate the kirby super user when creating new users.

to be listed at the offical kirby 3 plugin list you need to allow all three installation modes (composer, gitmodule and zip).

please check out the official example repo for a plugin with composer dependencies

it boils down to a special gitignore file and a reduced commited vendor folder. i know it's not the clean php composer way but it seems to be the best choice for kirby plugins.

apart from that i will certainly try out your plugin asap. ❤️

Hello,

First off, thanks a lot for making this plug-in.

I have a question about its use in the front-end. How would implement the plug-in via the front-end? Eg, what would be the bare minimum that needs to be included in a login.php file for example? Is each client a link to be verified?

Thanks again.

in lib/Controller.php line 131

You are checking whether an email is provided by Azure in upn (User Principal Name)

However in lib/Controller.php line 136

you overwrite the variable $email, regardless of previously provided email from upn

Fix

Swap the position of the above directives.
i.e.
The azure check should come after the loop which set vars from $oauthUserData

...

  foreach ($vars as $var) {
      $$var = isset($oauthUserData[$var]) ? $oauthUserData[$var] : null;
  }

//Azure Active Directory doesn't use "email" for email address, but "upn" for User Principal Name, and the email is always verified in Azure AD tenant
if(isset($oauthUserData["upn"])) {
    $email = $oauthUserData["upn"];
    $email_verified = true;
}


...

Best regards!

Hey @thathoff,

thanks for your work and keeping this plugin updated <3.

I'd like to implement a use case, where SSO/OAuth users have different groups on the Identity Provider (Nextcloud via https://github.com/bahuma20/oauth2-nextcloud in my case).

Any chance you see a way to implement a simple mapping between groups? E.g. if $provider->getResourceOwner($token)->getGroups() (documentation on the Provider side) contains admin, then assign Kirby group admin.

I'm not entirely sure how this could be configured in a nice and clean way. But this is quite a common use case for SSO/Oauth, right?

EDIT: For my use case a groupWhitelist could be enough, but it seems a proper mapping would still make sense as a general feature.

Currently this plugin has limited Kirby 4 support (eg. the Installation View breaks). Nevertheless the Login view still works with Kirby 4.

When I’m connected to the panel, for example at /panel/site, I can see the following error in the browser console:

SyntaxError: Unexpected token < in JSON at position 0

This is due to the code at https://github.com/blankogmbh/kirby-oauth/blob/master/index.js#L40-L41 being executed. The condition at https://github.com/blankogmbh/kirby-oauth/blob/master/index.js#L6 returning true (I guess that’s not the desired behavior, this code should be executed only on the panel login page).

Anyway, since the user is already connected, the async request to /oauth/settings returns a 302 that redirects to /panel, which itself return the panel home page as HTML resulting in the error above: the HTML response cannot be parsed as JSON.

I think the condition on line 6 should be adapter to be executed only on the login page or at least not when the user is already logged in.

Kirby 3.2.3
Kirby oauth 1.0.0