api/users : is it possible to force time related properties?

trivoallan

Hi,

I'm currently writing a script that can be used to migrate a Lussumo Vanilla forum to Flarum.
This script reads the Vanilla MySQL database and sends request to Flarum's HTTP API.

I'm working on migrating user accounts.

Is it possible to specify custom join_time, last_seen_time and read_time using Flarum's API?
If so, how? I tried setting those in JSON payload's data.attributes but it does not work.

luceos

You would first need to create an extension that listens on the create user event to add those fields (if submitted) to the user object. It then should have no issue with receiving such additional data through the API.

Toby

We could potentially add this to core. We did for post/discussion creation to support the same use-case. (Though in hindsight that is a faulty commit as it will only allow admin posts to have their time set manually. Instead, we should allow time and other attributes to be set regardless of the actor if the API request is authenticated using a master API key.)

Feel free to create an issue to allow setting more attributes on various resources.

trivoallan

Toby Thanks for your answer. I would be happy to implement such functionnality and provide a PR.
Yet, i am not familiar with the Flarum codebase. Could you give me few pointers that could help me get started?

luceos

trivoallan i recommend first creating the issue, so (other) developers are aware of the request. Next I'd recommend reading the read first.

Toby

trivoallan Like so:

Flarum\Http\Middleware\AuthenticateWithHeader: when the request is authenticated via an API key, set an attribute on the request to indicate that this is the case. (Currently we set an attribute called bypassFloodgate – we could rename this to be something more generalized, like "sudo".)
Flarum\Api\Controller\CreatePostController: either...
- Check for the presence of time and other protected attributes in the $data['attributes'] array before dispatching the domain command. If any are present and the request does not have the "sudo" attribute, throw a 403 Forbidden error.
- OR... Pass the "sudo" attribute as a new property on the PostReply command, and then guard those protected attributes according to its value in the Flarum\Core\Command\PostReplyHandler.

I just depends where we think that attribute protection logic belongs... In the API layer, or in the domain layer? Putting it in the API layer makes sense because it's determined by the method of API authentication, but then those attributes are left unguarded in the domain command if it's ever used in another context.

What do you think? /cc @Franz

Franz

Toby I'd say it probably belongs in the API layer. The models can have mass assignment protection and so on, but for concrete actions this should be fine in the HTTP interaction layer. Check out "strong parameters" in Ruby on Rails, that's quite similar, I think.

luceos

@Toby @Franz wouldn't this work with a simple permission, which is not visible in admin? You can then check for the permission with can on the actor. The "right" to do alleviated mutations should - in my opinion - belong to the actor, even if it's alleviated with a master key.