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

ipAddress request attribute not available when passing through API Client #2985

Closed
clarkwinkelmann opened this issue Jul 21, 2021 · 4 comments · Fixed by #3124
Closed

ipAddress request attribute not available when passing through API Client #2985

clarkwinkelmann opened this issue Jul 21, 2021 · 4 comments · Fixed by #3124
Assignees
Milestone

Comments

@clarkwinkelmann
Copy link
Member

Bug Report

Current Behavior
The user IP is not always available to extension middlewares that react to user login or registration. The IP is available when the user is logged in/created via the REST API but not when created via the web UI.

Steps to Reproduce
Use middleware

<?php

namespace MyExtension\Middlewares;

use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface;

class MyMiddleware implements MiddlewareInterface
{
    public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
    {
        if ($request->getUri()->getPath() === '/token') {
            var_dump($request->getAttribute('ipAddress'));
            die();
        }

        return $handler->handle($request);
    }
}

Register middleware on api:

return [
    (new Extend\Middleware('api'))
        ->add(Middlewares\MyMiddleware::class),
];

Perform request to POST /api/token or POST /api/users and notice IP is dumped.

Perform request to POST /login or POST /register and notice NULL is dumped.

Expected Behavior
In a way this could be intended behavior since the request is internal, but I don't think we ever intentionally made this and in any case there should be a way to find the original request IP from there.

The IP should be available, or at least the same default as 127.0.0.1 should be used instead of null.

Environment

  • Flarum version: 1.0.4

Possible Solution
The ipAddress request attribute should probably be copied over in the ApiClient like the session and actor are:

https://github.com/flarum/core/blob/104a31ba306d6298a70c7f011d46a6484c36fad2/src/Api/Client.php#L133-L137

I don't think it makes sense to re-run the ProcessIp middleware since that middleware already runs at the most early stages of the application. However there's the risk that a middleware under forum and a different middleware under api conflict in how they want to modify the attribute.

https://github.com/flarum/core/blob/eb4b18a979c7406cbf154a107662652d282fe415/src/Foundation/InstalledApp.php#L58

Additional Context
This affects my audit log extension that reads the IP during all requests.

@tankerkiller125
Copy link
Contributor

The reason for the ProcessIp middleware isn't just to set the attribute, the end goal is that it will also deal with Proxies and things of that nature to always return the client IP. We just haven't actually implemented that part. So I'm not sure how your fix would fit into that.

@luceos
Copy link
Member

luceos commented Aug 1, 2021

This makes a lot of sense.

@clarkwinkelmann
Copy link
Member Author

I think the value should be just kept verbatim and passed down, like the session attribute is. No need to process it twice.

@askvortsov1
Copy link
Member

Agreed. Iet's drop the middleware and pass the attribute explicitly.

@askvortsov1 askvortsov1 added this to the 1.1 milestone Aug 25, 2021
@askvortsov1 askvortsov1 modified the milestones: 1.1, 1.2 Sep 28, 2021
@SychO9 SychO9 added this to Roadmap Oct 1, 2021
@askvortsov1 askvortsov1 self-assigned this Oct 26, 2021
Repository owner moved this from Todo to Done in Roadmap Oct 26, 2021
@SychO9 SychO9 removed this from Roadmap Nov 1, 2021
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 a pull request may close this issue.

4 participants