You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Moltzau, Matthew" <Ma...@comcast.com> on 2018/09/14 20:41:01 UTC
Re: [EXTERNAL] Re: Removing uid and gid from user
Yes, this might also affect PUT for /api/*/user/current.
At least the documentation says that the gid and uid may be altered, though I don't currently know if that's actually the case.
On 9/14/18, 2:37 PM, "Jeremy Mitchell" <mi...@gmail.com> wrote:
Which endpoints are you talking about specifically?
GET /api/*/users
GET /api/*/users/:id
GET /api/*/user/current
^^ these ones?
Jeremy
On Fri, Sep 14, 2018 at 2:32 PM Moltzau, Matthew <
Matthew_Moltzau@comcast.com> wrote:
> Can I get a +1 to remove gid and uid from the user response in golang?
> They aren’t being used at all and are only ever set to null.
>
>
Re: [EXTERNAL] Re: Removing uid and gid from user
Posted by Robert Butts <ro...@apache.org>.
>the "confirmLocalPasswd" field (and related db column) should also be
deprecated
+1
On Sat, Sep 15, 2018 at 3:29 PM Dan Kirkwood <da...@gmail.com> wrote:
> +1 on this plan -- remove UID/GID from the db, keep (deprecated) in the API
> until the next major version of the API.
>
> Sorry to add to it, but the "confirmLocalPasswd" field (and related db
> column) should also be deprecated. Traffic Portal should keep this and
> check the fields as now, but only pass "localPasswd" to the Traffic Ops
> API. It should be ignored by the Traffic Ops API.
>
> Dan
>
> On Fri, Sep 14, 2018 at 2:46 PM Jeremy Mitchell <mi...@gmail.com>
> wrote:
>
> > Yeah, like Rob said, have to keep those fields because they are part of
> the
> > 1.x contract even though they are null...which does seem kinda silly but
> > api versioning is a promise...
> >
> > i would be curious if
> >
> > PUT api/*/users/:id
> > PUT api/*/user/current
> >
> > really allows you to change them and if it does even more of a reason to
> > keep them because maybe somebody is setting those id's for some reason...
> >
> > TO API 2.x we nix those imo (unless somebody is really using those
> fields)
> >
> > jeremy
> >
> > On Fri, Sep 14, 2018 at 2:41 PM Robert Butts <ro...@gmail.com>
> > wrote:
> >
> > > -1 on removing them from the API, they're part of API 1.x, we can't
> > remove
> > > them without breaking Semantic Versioning.
> > >
> > > +1 on removing from the db, hard-coding the API to return nulls, and
> > > documenting them as deprecated in the API. The db has no "version
> > promise",
> > > we can definitely clean that up.
> > >
> > >
> > > On Fri, Sep 14, 2018 at 2:41 PM Moltzau, Matthew <
> > > Matthew_Moltzau@comcast.com> wrote:
> > >
> > > > Yes, this might also affect PUT for /api/*/user/current.
> > > > At least the documentation says that the gid and uid may be altered,
> > > > though I don't currently know if that's actually the case.
> > > >
> > > > On 9/14/18, 2:37 PM, "Jeremy Mitchell" <mi...@gmail.com>
> wrote:
> > > >
> > > > Which endpoints are you talking about specifically?
> > > >
> > > > GET /api/*/users
> > > > GET /api/*/users/:id
> > > > GET /api/*/user/current
> > > >
> > > > ^^ these ones?
> > > >
> > > > Jeremy
> > > >
> > > > On Fri, Sep 14, 2018 at 2:32 PM Moltzau, Matthew <
> > > > Matthew_Moltzau@comcast.com> wrote:
> > > >
> > > > > Can I get a +1 to remove gid and uid from the user response in
> > > > golang?
> > > > > They aren’t being used at all and are only ever set to null.
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
>
Re: [EXTERNAL] Re: Removing uid and gid from user
Posted by Dan Kirkwood <da...@gmail.com>.
+1 on this plan -- remove UID/GID from the db, keep (deprecated) in the API
until the next major version of the API.
Sorry to add to it, but the "confirmLocalPasswd" field (and related db
column) should also be deprecated. Traffic Portal should keep this and
check the fields as now, but only pass "localPasswd" to the Traffic Ops
API. It should be ignored by the Traffic Ops API.
Dan
On Fri, Sep 14, 2018 at 2:46 PM Jeremy Mitchell <mi...@gmail.com>
wrote:
> Yeah, like Rob said, have to keep those fields because they are part of the
> 1.x contract even though they are null...which does seem kinda silly but
> api versioning is a promise...
>
> i would be curious if
>
> PUT api/*/users/:id
> PUT api/*/user/current
>
> really allows you to change them and if it does even more of a reason to
> keep them because maybe somebody is setting those id's for some reason...
>
> TO API 2.x we nix those imo (unless somebody is really using those fields)
>
> jeremy
>
> On Fri, Sep 14, 2018 at 2:41 PM Robert Butts <ro...@gmail.com>
> wrote:
>
> > -1 on removing them from the API, they're part of API 1.x, we can't
> remove
> > them without breaking Semantic Versioning.
> >
> > +1 on removing from the db, hard-coding the API to return nulls, and
> > documenting them as deprecated in the API. The db has no "version
> promise",
> > we can definitely clean that up.
> >
> >
> > On Fri, Sep 14, 2018 at 2:41 PM Moltzau, Matthew <
> > Matthew_Moltzau@comcast.com> wrote:
> >
> > > Yes, this might also affect PUT for /api/*/user/current.
> > > At least the documentation says that the gid and uid may be altered,
> > > though I don't currently know if that's actually the case.
> > >
> > > On 9/14/18, 2:37 PM, "Jeremy Mitchell" <mi...@gmail.com> wrote:
> > >
> > > Which endpoints are you talking about specifically?
> > >
> > > GET /api/*/users
> > > GET /api/*/users/:id
> > > GET /api/*/user/current
> > >
> > > ^^ these ones?
> > >
> > > Jeremy
> > >
> > > On Fri, Sep 14, 2018 at 2:32 PM Moltzau, Matthew <
> > > Matthew_Moltzau@comcast.com> wrote:
> > >
> > > > Can I get a +1 to remove gid and uid from the user response in
> > > golang?
> > > > They aren’t being used at all and are only ever set to null.
> > > >
> > > >
> > >
> > >
> > >
> >
>
Re: [EXTERNAL] Re: Removing uid and gid from user
Posted by Robert Butts <ro...@gmail.com>.
>i would be curious if
>
>PUT api/*/users/:id
>PUT api/*/user/current
>
>really allows you to change them and if it does even more of a reason to
>keep them because maybe somebody is setting those id's for some reason...
Well, if someone is using a TC data field for something outside TC, I don't
know that we promise to keep the data posted exactly as it was posted, and
return it exactly the same. For example, if you POST "httplivenatnl" and we
accept it, and you GET the data you just posted, you're going to get
"HTTP_LIVE_NATNL". Along those same lines, I'd argue that because TC
doesn't use `gid` or `uid` anymore, we're allowed to "manipulate" the data
posted, and return only the data relevant to TC, namely `null`.
It's certainly a grey area, and there's an argument we should preserve the
posted value, especially if it breaks someone in practice. But that's my
vote.
On Fri, Sep 14, 2018 at 2:50 PM Moltzau, Matthew <
Matthew_Moltzau@comcast.com> wrote:
> PUT api/*/users/:id
> Doesn't actually exist in v13 (which is perl for this particular endpoint)
>
> On 9/14/18, 2:46 PM, "Jeremy Mitchell" <mi...@gmail.com> wrote:
>
> Yeah, like Rob said, have to keep those fields because they are part
> of the
> 1.x contract even though they are null...which does seem kinda silly
> but
> api versioning is a promise...
>
> i would be curious if
>
> PUT api/*/users/:id
> PUT api/*/user/current
>
> really allows you to change them and if it does even more of a reason
> to
> keep them because maybe somebody is setting those id's for some
> reason...
>
> TO API 2.x we nix those imo (unless somebody is really using those
> fields)
>
> jeremy
>
> On Fri, Sep 14, 2018 at 2:41 PM Robert Butts <robert.o.butts@gmail.com
> >
> wrote:
>
> > -1 on removing them from the API, they're part of API 1.x, we can't
> remove
> > them without breaking Semantic Versioning.
> >
> > +1 on removing from the db, hard-coding the API to return nulls, and
> > documenting them as deprecated in the API. The db has no "version
> promise",
> > we can definitely clean that up.
> >
> >
> > On Fri, Sep 14, 2018 at 2:41 PM Moltzau, Matthew <
> > Matthew_Moltzau@comcast.com> wrote:
> >
> > > Yes, this might also affect PUT for /api/*/user/current.
> > > At least the documentation says that the gid and uid may be
> altered,
> > > though I don't currently know if that's actually the case.
> > >
> > > On 9/14/18, 2:37 PM, "Jeremy Mitchell" <mi...@gmail.com>
> wrote:
> > >
> > > Which endpoints are you talking about specifically?
> > >
> > > GET /api/*/users
> > > GET /api/*/users/:id
> > > GET /api/*/user/current
> > >
> > > ^^ these ones?
> > >
> > > Jeremy
> > >
> > > On Fri, Sep 14, 2018 at 2:32 PM Moltzau, Matthew <
> > > Matthew_Moltzau@comcast.com> wrote:
> > >
> > > > Can I get a +1 to remove gid and uid from the user response
> in
> > > golang?
> > > > They aren’t being used at all and are only ever set to null.
> > > >
> > > >
> > >
> > >
> > >
> >
>
>
>
Re: [EXTERNAL] Re: Removing uid and gid from user
Posted by "Moltzau, Matthew" <Ma...@comcast.com>.
PUT api/*/users/:id
Doesn't actually exist in v13 (which is perl for this particular endpoint)
On 9/14/18, 2:46 PM, "Jeremy Mitchell" <mi...@gmail.com> wrote:
Yeah, like Rob said, have to keep those fields because they are part of the
1.x contract even though they are null...which does seem kinda silly but
api versioning is a promise...
i would be curious if
PUT api/*/users/:id
PUT api/*/user/current
really allows you to change them and if it does even more of a reason to
keep them because maybe somebody is setting those id's for some reason...
TO API 2.x we nix those imo (unless somebody is really using those fields)
jeremy
On Fri, Sep 14, 2018 at 2:41 PM Robert Butts <ro...@gmail.com>
wrote:
> -1 on removing them from the API, they're part of API 1.x, we can't remove
> them without breaking Semantic Versioning.
>
> +1 on removing from the db, hard-coding the API to return nulls, and
> documenting them as deprecated in the API. The db has no "version promise",
> we can definitely clean that up.
>
>
> On Fri, Sep 14, 2018 at 2:41 PM Moltzau, Matthew <
> Matthew_Moltzau@comcast.com> wrote:
>
> > Yes, this might also affect PUT for /api/*/user/current.
> > At least the documentation says that the gid and uid may be altered,
> > though I don't currently know if that's actually the case.
> >
> > On 9/14/18, 2:37 PM, "Jeremy Mitchell" <mi...@gmail.com> wrote:
> >
> > Which endpoints are you talking about specifically?
> >
> > GET /api/*/users
> > GET /api/*/users/:id
> > GET /api/*/user/current
> >
> > ^^ these ones?
> >
> > Jeremy
> >
> > On Fri, Sep 14, 2018 at 2:32 PM Moltzau, Matthew <
> > Matthew_Moltzau@comcast.com> wrote:
> >
> > > Can I get a +1 to remove gid and uid from the user response in
> > golang?
> > > They aren’t being used at all and are only ever set to null.
> > >
> > >
> >
> >
> >
>
Re: [EXTERNAL] Re: Removing uid and gid from user
Posted by Jeremy Mitchell <mi...@gmail.com>.
Yeah, like Rob said, have to keep those fields because they are part of the
1.x contract even though they are null...which does seem kinda silly but
api versioning is a promise...
i would be curious if
PUT api/*/users/:id
PUT api/*/user/current
really allows you to change them and if it does even more of a reason to
keep them because maybe somebody is setting those id's for some reason...
TO API 2.x we nix those imo (unless somebody is really using those fields)
jeremy
On Fri, Sep 14, 2018 at 2:41 PM Robert Butts <ro...@gmail.com>
wrote:
> -1 on removing them from the API, they're part of API 1.x, we can't remove
> them without breaking Semantic Versioning.
>
> +1 on removing from the db, hard-coding the API to return nulls, and
> documenting them as deprecated in the API. The db has no "version promise",
> we can definitely clean that up.
>
>
> On Fri, Sep 14, 2018 at 2:41 PM Moltzau, Matthew <
> Matthew_Moltzau@comcast.com> wrote:
>
> > Yes, this might also affect PUT for /api/*/user/current.
> > At least the documentation says that the gid and uid may be altered,
> > though I don't currently know if that's actually the case.
> >
> > On 9/14/18, 2:37 PM, "Jeremy Mitchell" <mi...@gmail.com> wrote:
> >
> > Which endpoints are you talking about specifically?
> >
> > GET /api/*/users
> > GET /api/*/users/:id
> > GET /api/*/user/current
> >
> > ^^ these ones?
> >
> > Jeremy
> >
> > On Fri, Sep 14, 2018 at 2:32 PM Moltzau, Matthew <
> > Matthew_Moltzau@comcast.com> wrote:
> >
> > > Can I get a +1 to remove gid and uid from the user response in
> > golang?
> > > They aren’t being used at all and are only ever set to null.
> > >
> > >
> >
> >
> >
>
Re: [EXTERNAL] Re: Removing uid and gid from user
Posted by Robert Butts <ro...@gmail.com>.
-1 on removing them from the API, they're part of API 1.x, we can't remove
them without breaking Semantic Versioning.
+1 on removing from the db, hard-coding the API to return nulls, and
documenting them as deprecated in the API. The db has no "version promise",
we can definitely clean that up.
On Fri, Sep 14, 2018 at 2:41 PM Moltzau, Matthew <
Matthew_Moltzau@comcast.com> wrote:
> Yes, this might also affect PUT for /api/*/user/current.
> At least the documentation says that the gid and uid may be altered,
> though I don't currently know if that's actually the case.
>
> On 9/14/18, 2:37 PM, "Jeremy Mitchell" <mi...@gmail.com> wrote:
>
> Which endpoints are you talking about specifically?
>
> GET /api/*/users
> GET /api/*/users/:id
> GET /api/*/user/current
>
> ^^ these ones?
>
> Jeremy
>
> On Fri, Sep 14, 2018 at 2:32 PM Moltzau, Matthew <
> Matthew_Moltzau@comcast.com> wrote:
>
> > Can I get a +1 to remove gid and uid from the user response in
> golang?
> > They aren’t being used at all and are only ever set to null.
> >
> >
>
>
>