Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

raise default auth events #45

Conversation

okaufmann
Copy link
Contributor

@okaufmann okaufmann commented Nov 10, 2021

Hi,

The Laravel SessionGuard dispatches several events, which can be used to listen when a user logs in etc...

JWTGuard already dispatched some of these events and I just added the other ones, that make sense.

@Messhias
Copy link
Collaborator

Hi @okaufmann , thanks for your contribution, can you add some tests case to cover your code? Doesn't need to be very complex, but let's keep the code coverage (or at least most of it).

If it's not possible please let me know.

Thank you,

@okaufmann okaufmann force-pushed the feature/raise-default-auth-events branch 2 times, most recently from e476d91 to 85d452b Compare November 10, 2021 15:49
@okaufmann
Copy link
Contributor Author

okaufmann commented Nov 10, 2021

Hi @Messhias

Thanks for your prompt response!

Of course, I extended the tests for these events.

Let me know if I forgot something.

Copy link
Contributor

@mfn mfn left a comment

Choose a reason for hiding this comment

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

Hi 👋🏼 ,

thanks for the PR, overall LGTM but it's clear some of the comments are a copypaste from somewhere else (SessionGuard?); nothing wrong with that, but they're not technical correct.

WDYT about my feedback?

src/JWTGuard.php Outdated
Comment on lines 199 to 194


Copy link
Contributor

Choose a reason for hiding this comment

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

Can you please remove those empty lines?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

src/JWTGuard.php Outdated
@@ -167,6 +170,11 @@ public function login(JWTSubject $user)
$token = $this->jwt->fromUser($user);
$this->setToken($token)->setUser($user);

// If we have an event dispatcher instance set we will fire an event so that
Copy link
Contributor

Choose a reason for hiding this comment

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

If we have an event dispatcher instance set

I don't read anything in the code where the event dispatcher is option; it's injected via DI and is required, so I think the comment isn't technically correct.

My other feedback here is: the method is called fireLoginEvent

The comment spawns 3 lines essentially telling us this.

My TL;DR feedback here would: method name is good and very clear, we don't need the comment at all

Copy link
Contributor Author

@okaufmann okaufmann Nov 11, 2021

Choose a reason for hiding this comment

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

Well, i did just copy this from the SessionGuard without thinking about it. I removed it ^^

src/JWTGuard.php Outdated
// If we have an event dispatcher instance, we can fire off the logout event
// so any further processing can be done. This allows the developer to be
// listening for anytime a user signs out of this application manually.
$this->events->dispatch(new Logout($this->name, $this->user));
Copy link
Contributor

Choose a reason for hiding this comment

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

It feels inconsistent when all other events are wrapped in dedicated protected fire*Event methods but this one isn't.

My suggestion:

  • remove the comment (same reason as with the other comment)
  • add a dedicated fireLogoutEvent

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

src/JWTGuard.php Outdated
@@ -501,6 +533,33 @@ protected function fireFailedEvent($user, array $credentials)
));
}

/**
* Fire the authenticated event if the dispatcher is set.
Copy link
Contributor

Choose a reason for hiding this comment

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

if the dispatcher is set.

This isn't correct: the dispatcher is always present

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

src/JWTGuard.php Outdated
}

/**
* Fire the login event if the dispatcher is set.
Copy link
Contributor

Choose a reason for hiding this comment

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

if the dispatcher is set.

This isn't correct: the dispatcher is always present

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@okaufmann
Copy link
Contributor Author

@mfn Hi Markus, you are absolutely right! Thanks for your time and review.

Sorry for the shitty PR, I cleaned up all the things you mentioned and hope it's now clean and correct.

Copy link
Contributor

@mfn mfn left a comment

Choose a reason for hiding this comment

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

Sorry for the shitty PR

FTR, I don't think so at all!

Also, thanks for initial version which prompted my code style comment; it prompted me to do #46 which was already accepted 😏

LGTM!

ps: I'm just a contributor like you, not a member, cannot merge stuff

src/JWTGuard.php Outdated
Comment on lines 380 to 395
/**
* Set the current user.
*
* @param \Illuminate\Contracts\Auth\Authenticatable $user
* @return $this
*/
public function setUser(Authenticatable $user)
{
$this->user = $user;

$this->fireAuthenticatedEvent($user);

return $this;
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Just a note for myself: setUser is part of the interface and was covered by a trait so far (that's why it's not in this class), this basically re-implements it and adds the event dispatch.

Technically we could still call the trait version via an alias to not have redundant code, but I guess for the user set this would take things to far 😄

Copy link
Collaborator

Choose a reason for hiding this comment

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

So it isn't better to move straight to trait and do everything in this PR?

Copy link
Contributor

Choose a reason for hiding this comment

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

sorry, "parser error" 😬 Can you re-phrase maybe?

Copy link
Contributor Author

@okaufmann okaufmann Nov 11, 2021

Choose a reason for hiding this comment

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

Laravel also overwrites setUser for the same reason: https://github.com/laravel/framework/blob/8.x/src/Illuminate/Auth/SessionGuard.php#L923

That's why I did it the same way...

The goal was to raise the same events as SessionGuard where it is possible, and for setUser an Authenticated event should be raised.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@mfn on that case it's seems we're facing a limitation of the Laravel framework for setUser since it's overridden.

@okaufmann does that would harm the library? As I far I did see any problem at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm you're right, this is a risk when Laravel changes the behaviour of setUser in its Auth Guards. But this is not a breaking change at all, as it does only raise an event now. When no one listens for this event, nothing happen. Maybe you should note it in the Release notes.

So I think we can risk it. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

well yes, this is what I was insinuating with the alias; to be on the safe side we could do this (untested):

diff --git a/src/JWTGuard.php b/src/JWTGuard.php
index ba02510..b89a0ab 100644
--- a/src/JWTGuard.php
+++ b/src/JWTGuard.php
@@ -31,7 +31,10 @@ use PHPOpenSourceSaver\JWTAuth\Exceptions\UserNotDefinedException;
 
 class JWTGuard implements Guard
 {
-    use GuardHelpers, Macroable {
+    use GuardHelpers {
+        setUser as guardHelperSetUser;
+    }
+    use Macroable {
         __call as macroCall;
     }
 
@@ -385,11 +388,11 @@ class JWTGuard implements Guard
      */
     public function setUser(Authenticatable $user)
     {
-        $this->user = $user;
+        $result = $this->guardHelperSetUser($user);
 
         $this->fireAuthenticatedEvent($user);
 
-        return $this;
+        return $result;
     }
 
     /**

WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great idea! Seems to work as well.

@okaufmann okaufmann force-pushed the feature/raise-default-auth-events branch 2 times, most recently from 7ac7755 to dd81b7d Compare November 12, 2021 13:11
Copy link
Contributor

@mfn mfn left a comment

Choose a reason for hiding this comment

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

👍🏼

@okaufmann
Copy link
Contributor Author

@Messhias Please let me know if there is anything I can do so this can be merged and release 💪

@Messhias
Copy link
Collaborator

@Messhias Please let me know if there is anything I can do so this can be merged and release 💪

All the tests failed, can you check that?

@okaufmann okaufmann force-pushed the feature/raise-default-auth-events branch from dd81b7d to dec077e Compare November 16, 2021 12:08
@okaufmann
Copy link
Contributor Author

okaufmann commented Nov 16, 2021

@Messhias Completed the tests and fixed duplicate Attempting event.

Can you trigger the tests again?

@Messhias
Copy link
Collaborator

@Messhias Completed the tests and fixed duplicate Attempting event.

Can you trigger the tests again?

Great work, thanks :)

@Messhias Messhias merged commit f68d286 into PHP-Open-Source-Saver:develop Nov 16, 2021
@okaufmann
Copy link
Contributor Author

@Messhias would you mind creating a new release containing these changes?

@okaufmann okaufmann deleted the feature/raise-default-auth-events branch November 16, 2021 15:49
@Messhias
Copy link
Collaborator

@Messhias would you mind creating a new release containing these changes?

No problem, me and @eschricker we'll do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants