PSR-7 URI Interface userInfo question

[Robert Crous]

Hi all,

I understand that `Uri(some_url)->userInfo` returns the result of `parse_url(some_url)[user]` (and then optionally append ':' . [pass]).

My question is: why are there no setters and getters available for `user` and `pass`?

I can't see any reason why having getters/setters available for user + pass would disrupt anything and it seems fairly odd that the decision was made to replace this with `getUserInfo` and `withUserInfo`.

But is there a specific reason why this was done?

And if not- is there any way this can be added to the spec for the URI interface?

Kind Regards,

Rob

[Alexandru Pătrănescu]

Hi Rob,

In UriInterface there is this method:

public function withUserInfo($user, $password = null): UriInterface;  

https://github.com/php-fig/http-message/blob/master/src/UriInterface.php#L207  

I guess this is what you want.

Regards

Alex

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/b45e38a2-222c-4b3a-afb6-bd2f130547f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Crous]

Hey Alex!

Not quite, I do know of it's existence but I'm actually wanting to have access to something along the lines of...

public function setUser()
{
    return $this->user;
}

Problem with the current set of methods is that I am unable to get the password out of Uri without doing string 'hackery' outside of the spec of this interface.

Hence me suggesting one should be added :)

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAwdEzD%2B27j25hv%2B1bPWaLXiX37rvgFUkAVQV-sdsGm45bk-Jg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Kind Regards,

Robert Crous

[Nicholas Ruunu]

Hi Rob,

It's not replacing anything, userinfo is part of URI: https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

It would be stranger to deal with user/pass imo since that'd be more of an abstraction.

[Alexandru Pătrănescu]

Hi Rob,

Can you show an example of what you try to achieve and it's not working without the a setUser() method?

Are you working with a specific implementation?

Please keep in mind that most of the entities in PSR-7 are immutable, including UriInterface.

You can read also meta document to understand design decision: https://www.php-fig.org/psr/psr-7/meta/

Regards,

Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAOEKAZzRawBfTxAJPjfR59PGvYVJUSrBAM4OZNbxgppG-j1ofA%40mail.gmail.com.

[Robert Crous]

Hi Alex,

Will read through the meta document shortly.

My use case is that I need to return a string of a url without the password parameters.

The string is set in the environment but follows the structure of - `https://<user>:<password>@<domain>.com/<number>`

I need to pass `https://<user>@<domain>.com/<number>` to a template so that I can init a sentry js sdk.

This would be trivial if I was able to remove `pass` param from the URI object, but unfortunately I can't so I need to do the following:

```

        $uri = new Uri(config('sentry.dsn'));

        $user = $uri->getUserInfo();

        $user_parts = explode(':', $user);

        $uri_without_pass = $uri->withUserInfo($user_parts[0]);

        return (string) $uri_without_pass;
```

This is still simple, I just feel like it is a dangerous assumption to explode on (':') just to rebuild the Uri without a password.

I feel like it would be more elegant to remove the password property from the Uri object which is not possible in the current spec.

> Are you working with a specific implementation?

I'm using GuzzleHttp\Psr7\Uri

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAwdEzBpPk1kLNUDh8XE2B9gV4h%3D08ofeh-GSSirPXCoR%2BkppQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Matthew Weier O'Phinney]

On Mon, Mar 18, 2019 at 8:37 AM Robert Crous <robert....@gmail.com> wrote:

I understand that `Uri(some_url)->userInfo` returns the result of `parse_url(some_url)[user]` (and then optionally append ':' . [pass]).

My question is: why are there no setters and getters available for `user` and `pass`?

I can't see any reason why having getters/setters available for user + pass would disrupt anything and it seems fairly odd that the decision was made to replace this with `getUserInfo` and `withUserInfo`.

But is there a specific reason why this was done?

There is a reason: because the user-info segment of a URI is not limited to user/pass combinations, and user/pass combinations are, in fact, deprecated, per RFC 3986 Section 3.2.1: https://tools.ietf.org/html/rfc3986#section-3.2.1

This is also why we do not provide separate "getter" methods for the user/pass. When using that functionality, the onus is on the user to know that both fields are present, and to split them manually. (Having additional methods did not make sense, since the functionality can be accomplished in userland code using the available methods.)

As such, we provide the following methods only:

- getUserInfo(), which will return the full user-info segment

- withUserInfo(string $user, ?string $password = null) : UriInterface, which allows creating and returning a new instance with the provided user-info data.

As noted elsewhere in this thread, the majority of interfaces in the specification are marked immutable, and the way to create variants of any given instance is via the various `with*()` methods. This decision is documented in the meta document.

 

And if not- is there any way this can be added to the spec for the URI interface?

Kind Regards,

Rob

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/b45e38a2-222c-4b3a-afb6-bd2f130547f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

he/him

[Robert Crous]

Thanks Matthew!

That is exactly what I couldn't find. I appreciate the link and agree with all of your points!

Can I suggest that, as per definition of the second parameter - "optionally,

   scheme-specific information about how to gain authorization to access

   the resource.", the parameter name ( along with the  description ) gets changed from `$password` to `$authorizationParameter` or something more generic than password?

[Larry Garfield]

That assumes a user info is always user:password, which is not the case. It could be some other format of string. Hard-coding one particular format into the spec would be limiting.

You've already noted that parsing the string yourself is only a few lines of code. Moving those few lines of code into the class wouldn't buy much, especially given that it's non-standard.

Besides, specs once approved are not subject to change so we couldn't simply add such a method now anyway without a new PSR. :-)

--Larry Garfield

On Mon, Mar 18, 2019, at 9:43 PM, Robert Crous wrote:
> Ah,
>
> I see, this is the part that I missed,
>
> As userinfo is a subcomponent would it not make sense to have an
> interface for this so that we can have access to the user and
> (optional) password properties on it?