Access the payload of request about lux HOT 13 CLOSED

You should be able to access the request object http.IncomingMessage. Here is an example of how you would do so.

import { Controller } from 'lux-framework';

import Post from '../models/post';

class PostsController extends Controller {
  beforeAction = [
    function logHeaders(request) {
      console.log(request.headers);
    }
  ];

  index(request) {
    return Post.where(request.params.filter);
  }
}

export default PostsController;

Do you have an example of where you are trying to access the request object?

from lux.

I have a custom POST action where I need to munge the payload of the request.

I can't access the payload on the request.

from lux.

Custom actions should behave exactly like built in actions. Are you adding the POST action via a controller action? Do you mind including a code snippet?

from lux.

The body of the request is what I am after.

In my router I have

this.route('users/login', {
  action: 'login',
  method: 'POST'
});

In my users controller I have

login(request, response) {
    // this is where I need to get username and password
}

from lux.

Ok this makes more sense now. The body is parsed by Lux into params so you do not have access to the raw body. If you need to access the "body" try to access the data via the request.params Object.

Also, be sure to whitelist any keys that you don't want to filter out during the parameter sanitization process for security reasons.

import { Controller } from 'lux-framework';

import User from '../models/user';

class UsersController extends Controller {
  params = [
    'username',
    'password'
  ];

  beforeAction = [
    function logParams({ params }) {
      // Check to see if the params are making there way through to the controller.
      console.log(params);
    }
  ];

  login({ params: { username, password } }) {
    return User.authenticate(username, password);
  }
}

export default PostsController;

Let me know if that works for you.

from lux.

Maybe I am not doing in the right place?

What is the more appropriate?

from lux.

What is the more appropriate?

See the comment above. We're currently working on a website with better guides and documentation.

from lux.

I've just tried your suggestion and it does not appear in params :(

As I understand params are created from query string. I am sending my payload in the body of the request.

I am a little confused on why there's no access to the body of the request by design.

It seem to me that it is a common scenario to validate and insert business logic prior to saving a model but maybe that is not what this framework is for.

from lux.

As I understand params are created from query string. I am sending my payload in the body of the request.

The params are created from the dynamic url segments and the query string for GET requests, POST and PATCH requests also use the body parser to parse the body into a JSON object that is sanitized for security and convenience.

What your trying to do should work as long as the params are whitelisted and the body your expecting is valid JSON (see #218).

After work today I can help debug this further and see if I can reproduce this issue.

from lux.

Thanks for that. I really appreciate it.

I must say that the framework looks extremely promising and the code quality is mind blowing.

I'd like to help to contribute maybe with something like docs to start with. Let me know what I can help with.

from lux.

Thank you! That really means a lot. We would love to have you contribute in any way possible. Creating this issue is a huge help and a great way to start.

Let me know what I can help with.

I'll find something for you this evening after 6 PM (EDT)!

from lux.

First and foremost, thank you for taking the time to create this issue, trying out Lux, and your enthusiasm to help us out. It is all very much appreciated! 😃

So I did a little bit of debugging and think I may know what is causing your issue here. Since Lux is exclusively JSON API the POST requests are expected to be JSON API spec compliant. With that being said make sure the client you are using to make the request is including a Content-Type header with the value application/vnd.api+json. Also the data you are sending is formatted the way create and update actions are expected to be formatted, which is a JSON object containing a top level data object with a type property and an attributes object containing the fields you want to use for authentication.

This is kind of a grey area as to wether or not this should be an issue. The thing is, currently Lux is exclusively JSON API compliant and it will remain that way for the foreseeable future. I think I'm going to close this issue and open a new one to ensure that requests that are not compliant receive a 400 Bad Request response. After #222 and #229 merge, ensuring that non JSON API (POST and PATCH) request payloads actually would be a good first bug for you to tackle if your up for it. 😉

I included a sample request I used to get this working as well as a UsersController containing the login action example.

POST /users/login HTTP/1.1
Accept: application/vnd.api+json
Content-Type: application/vnd.api+json
Host: localhost:4000
Connection: close
User-Agent: Paw/2.3.4 (Macintosh; OS X/10.11.6) GCDHTTPRequest
Content-Length: 188

{
  "data": {
    "type": "users",
    "attributes": {
      "email": "[email protected]",
      "password": "super-secret-password"
    }
  }
}

import { Controller } from 'lux-framework';

import User from '../models/user';

class UsersController extends Controller {
  params = [
    'name',
    'email',
    'password'
  ];

  login({
    params: {
      data: {
        attributes: {
          email,
          password
        }
      }
    }
  }) {
    return User.authenticate(email, password);
  }
}

export default UsersController;

Anyways, let me know if your able to proceed with making POST requests to your custom login action. If your still having trouble I would be happy to chat and debug w/ you in real time in our Gitter room.

from lux.

That worked! Thanks so much!

Which part of lux is responsible for producing those errors? I'm going to look into it to return the appropriate errors and create a PR.

Also, what is the best way to chat to you directly outside of github?

from lux.