Question on Request and Response Cookies about dflydev-fig-cookies

[simensen]

Hello @Lewiscowles1986! You should be able to read and write both Request cookies (Cookie header; Cookie) and Response cookies (Set-Cookie header; SetCookie). If there this question comes from the fact that the classes are named Cookies (dealing with request cookies) and SetCookies (dealing with response cookies) then perhaps some additional documentation is needed to make it clear what is going on. If there is some other confusion (or if I've missed your point entirely) then perhaps you can show me examples of what looks wrong/broken to you and I'll see if I can either answer them or put it on the list of things todo.

[Lewiscowles1986]

Hi Simensen, this is not a bug report, I am more interested in understanding the rationale or use-case behind setting a cookie on a request, or retrieving one from a response (i.e. why would this happen). AFAIK it cannot happen using native PHP cookies, so perhaps because of this I have never seen the use-case, which is why I was asking what it is practically?

[simensen]

@Lewiscowles1986 I see! We are not limited by PHP's cookie handling restrictions with PSR-7 or other HTTP abstraction layers. So it is entirely possible you cannot set request cookies with PHP.

As for a use case, the one I was aware of was encrypted cookies. You can see a sample implementation of this here:

• https://github.com/laravel/lumen-framework/blob/5.1/src/Application.php#L1163

What this does is rewrites incoming cookies and outgoing set cookies so that it is "encrypted" outside the middleware and "decrypted" inside the middleware.

There are two things to keep in mind with respect to PSR-7 requests and responses. The server handling is only part of it. You could just as easily use this on a client implementation as well.

Does that help answer the questions any?

[Lewiscowles1986]

I think I get it... So the cookie can be set on a Request, so that you can send that Request via a PHP application component (something like guzzle, that uses PSR compliant Request), which will manifest as a client to another app, and receive a Response, which you may need to read the cookies from?

It sounds like a magical way to work lol, I'll be avoiding it 😉

[ve3]

I'm confuse about this. I set both cookie and setCookie but nothing changed.

public function indexAction(ServerRequestInterface $request, ResponseInterface $response)
    {
        $setCookie = FigResponseCookies::get($response, 'setcookie_tokentest', 'nothing');
        print_r($setCookie);
        echo $setCookie;
        echo '<br>';
        echo '<hr>';

        $reqcookie = FigRequestCookies::get($request, 'cookie_tokentest', 'no');
        print_r($reqcookie);
        echo $reqcookie;
        echo '<br>';
        echo '<hr>';

        $response = FigResponseCookies::set($response, SetCookie::create('setcookie_tokentest')
            ->withValue('aaaa')
        );
        print_r($response);
        echo '<br>';
        echo '<hr>';

        $request = FigRequestCookies::set($request, Cookie::create('cookie_tokentest', 'yes'));
        print_r($request);
        echo '<br>';
        echo '<hr>';
    }

This is class constructor in Slim.

The cookie was not set. The first two get from request cookies and response cookies has nothing change after set and reload the page.
I'm also did not know how to get the value from get to use because it is something like this. cookie_tokentest=no Do I have to explode it?
What is the different with $_COOKIES of php itself?

[simensen]

@ve3 I'm not sure what you are expecting to happen here.

You are calling get on both $response and $request. In theory, if nothing else has ever set the cookies on the incoming $request or $response, you should expect to get 'nothing' and 'no' values back.

You are calling set on both $response and $request and you are reassigning the variables, which is correct. When you do so, $response and $request should have the values that you specified: 'aaaa' and 'yes'.

The only thing that can impact the cookie in the future is if you then do something with that response, like return it or emit it in some way. If you do, the cookie should be set on the client. It should then have a value ('aaaa') in the $request on future calls.

I don't know what the rest of your action looks like so I cannot tell you what else is wrong. However, if you're not passing back $response in some way then it is not surprising in any way that the cookie is never actually set.

I'm also did not know how to get the value from get to use because it is something like this. cookie_tokentest=no Do I have to explode it?

You should be able to call $cookie->getValue() or $setCookie->getValue() to get just the value part. If you try to stringify a $cookie or $setCookie you will end up with the string representation of a cookie ('name=value'): https://github.com/dflydev/dflydev-fig-cookies/blob/master/src/Dflydev/FigCookies/Cookie.php#L63

What is the different with $_COOKIES of php itself?

With PHP $_COOKIES, those are populated once for the entire lifetime of the inbound request. It is also not available for CLI applications since there would be no way for the cookies to actually get to the CLI application.

With this library, we are not operating on a global "this is the set of cookies that PHP was sent when the request started," but instead are operating on the cookies that are embedded in a PSR-7 request or set cookies that are embedded in a PSR-7 response.

This means that you can use this library to handle cookie related tasks for both server based software and client based somewhere. This library works directly on the Cookie and Set-Cookie headers embedded in the underlying HTTP Message object inside PSR-7 requests and responses.

---

I hope this helps answer the questions and makes it more clear as to what is going on here?

[ve3]

That is all the code I have. I confused because there is no example of the code that worked to set and get the cookie value.