scottbedard/rainlab-user-api

A simple and extendable HTTP API for RainLab.User plugin

rainlab-user-api's Issues

afterGetUser event is not fired after creating a user

The response from creating a user should be the same as fetching the authenticated user. Right now we have inconsistent data being returned if the response is being extended.

Improve mail assertions

Leaving this here as a reminder to future me, mail assertions can be cleaned up by using Alxy's mail fake.

https://gist.github.com/alxy/6e74d306be7bd0c9d1f134f34d547a44

Example usage:

public function testNewFakeMailer()
{
    Mail::swap(new MailFake());

    // These variables are available inside the message as Twig
    $vars = ['name' => 'Joe', 'user' => 'Mary'];

    Mail::send('backend::mail.invite', $vars, function($message) {
        $message->to('[email protected]', 'Admin Person');
        $message->subject('This is a reminder');
    });

    Mail::assertSent('backend::mail.invite', function (Mailable $mailable) use ($vars) {
        return $mailable->viewData['name'] === 'Joe' &&
            $mailable->viewData['user'] === 'Mary' &&
            $mailable->hasTo('[email protected]');
    });
}

Return better status code when authenticating as banned user

We are currently returning a 500 status code when authenticating as a banned user. It is probably more appropriate to return a 405, but there are issues with checking the throttled status of a user before authenticating them.

See this issue for more information
rainlab/user-plugin#413

Invalid account updates should return 422

Right now we're getting validation errors for account updates returned as a 500, these should be a 422

Changing the authenticated user's password signs the user out

See: https://github.com/rainlab/user-plugin/blob/master/components/Account.php#L419-L424

Steps to reproduce

1. Submit a request to change your password

Expected result

The password should be changed, and you should remain logged in.

Actual result

The password changes, but you are not logged in.

auto activation is broken

Steps to reproduce

1. Set activation mode to auto
2. Create a user

Expected result

The user should be auto activated.

Actual result

The user is not activated.

1.0 announcement

The next releases will contain a breaking change to all endpoints, and will begin the official versioning of this plugin.

What's being changed

We are no longer going to catch our own exceptions.

In hind sight, this was never the best way to do things. Every application is going to need to handle errors for their own endpoints. Having our plugin catch its own errors forces the consuming applications to pick from the following options, both of which are pretty unappetizing.

• They can adopt our exception handling strategy for consistency, giving up the ability to handle their own errors how they like.

• Or they can have multiple error handling strategies. This is probably the worse of the two options, as now they would need to remember which endpoints respond which ways.

Going forward

Applications should use October's default error responses. Uncaught exceptions already have explicit status codes and store necessary meta data in the headers.

As an added benefit we are opting into October's default error formatting, giving us nice stack traces in development.

Existing applications that wish to continue handling the exceptions as we previously did must now catch the exceptions themselves. As an example, adding this to your boot.php file would catch all of our validation errors.

App::error(function(ValidationException $err) {
    return [
        // ...
    ];
});

Settings models don't fire model.getAttribute events

Settings models do not fire model.getAttribute events when the static get method is called. Because of this, plugins are unable to define user configuration by listening for that event. For example, this would have no effect on the API.

UserSettings::extend(function($model) {
  $model->bindEvent('model.getAttribute', function($attribute) {
    if ($attribute === 'login_attribute') {
      return UserSettings::LOGIN_USERNAME;
    }
  });
});

To side-step this issue, we should be able to use an instance of the settings model rather than the get method.

// before
UserSettings::get('login_attribute', $default);

// after
UserSettings::instance()->login_attribute ?: $default;

Registering with a taken username / email should return 422

Steps to reproduce

1. Sign up with a username or email that is already taken

Expected result

A 422 status code should be returned with validation errors.

Actual result

500 status code

Why don't you share on the marketplace? Is it possible to disallow some routes?

Hi Scott,

I've found this repo which could be helpful in a project I'm currently working on where I need to share an auth session between a Laravel app and an OctoberCMS installation.

I've looked on the marketplace and didn't find it there so I'm asking why? Does it contain some kind of issue or that kind of stuff? Maybe I can help.

Also a little question: is it possible to disallow some routes? Basically I just want to be open the login/logout routes. I know I can prevent users to access it by creating a custom routes.php with the same routes and require it before you're but if it's directly possible in your package, it's nice!