On Tue, Jun 16, 2020 at 12:33 PM Mark Fletcher <email@example.com> wrote:
On Mon, Jun 15, 2020 at 5:13 PM Jordan Evans <firstname.lastname@example.org> wrote:
It was removed on May 26th as part of a fix for a bug preventing the in-development app from logging in on domains other than groups.io
I noticed that the domain parameter for the login endpoint was removed
(https://groups.io/api#login). I don't recall when that happened, but
it seemed the parameter worked until fairly recently. I have a couple
of related questions:
It should all work as before except you need to log in using the domain in the URL instead of as a parameter. Nothing else changed. The token parameter should work; if it doesn't please let me know the URL you're using to log in and I'll investigate.
1. Are we expected to auth against the actual domain now? (for
example, https://lists.onap.org/api/v1/login instead of
previously used the domain parameter to determine if
an enterprise setup was already deployed for a given domain.
2. Does the token parameter for login currently work? It seems I still
get a cookie and the response appears unchanged.
Yep, I missed the token response in the bottom of the JSON response.
In terms of trying to determine if a group is set up or not, I would think that the login call wouldn't resolve since the DNS setup wouldn't be complete yet. Could you use that as an indicator?
My reluctance with that is that we don't want to send groups.io
credentials/tokens to a potential third-party. From testing, it
appears if I make the call to https://groups.io/api/v1/login
modified Host header, it works as expected, and I don't worry about
sending credentials to other parties.