Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(invite) add email autocomplete in invite #14610

Merged
merged 13 commits into from
Aug 1, 2024

Conversation

raphaelbadawi
Copy link
Contributor

This is the follow up to this discussion in which the specs were discussed.

This adds an autocomplete for mere emails. Since emails are not Jitsi entity types, this also adds an alternative authentication mechanism for directories holding external entities (this authentication mechanism was also discussed in the issue above).

The documentation for this has been written too, here is the PR for this part => jitsi/handbook#503

Thanks!

@jitsi-jenkins
Copy link

Hi, thanks for your contribution!
If you haven't already done so, could you please make sure you sign our CLA (https://jitsi.org/icla for individuals and https://jitsi.org/ccla for corporations)? We would unfortunately be unable to merge your patch unless we have that piece :(.

@raphaelbadawi
Copy link
Contributor Author

Hello,

Here is the CLA signed by my CEO.

8x8_Corporate_CLA_rev.20181129.docx.pdf

Dev list.pdf

Best regards,
Raphaël.

Copy link

This PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Jul 12, 2024
@saghul
Copy link
Member

saghul commented Jul 12, 2024

PIng @damencho

Copy link
Member

@damencho damencho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are also a lot of lint errors.

): Promise<any> {

if (!inviteItems || inviteItems.length === 0) {
return Promise.resolve();
}

// Parse all the query strings of the search directory endpoint
const params = new URLSearchParams();
params.append('jwt', jwt);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This adds jwt to the URL params. This reverts behavior that was dropped in 9af0003.

// Authentication params for external entities (e. g. email)
if (peopleSearchTokenLocation && peopleSearchTokenKey) {
const peopleSearchToken = localStorage.getItem(peopleSearchTokenLocation) ?? "";
params.append(peopleSearchTokenKey, peopleSearchToken);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need a second token parameter. Can't you use Authorization': `Bearer headers that are added.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you give more details on this one?
So the token is stored in localstorage? Who is storing it there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a good question. The whole idea is to be able to authenticate against directories on instances where JWT is not enabled. In our case we added a little fetch request to our auth service at the bottom of index.html which retrieves the token if there is an active session.

What we added to index.html is very straightforward and looks like this:

document.addEventListener("DOMContentLoaded", () => {
  fetch("{{SERVER}}/api/login/token", { credentials: "include" })
    .then((response) => response.json())
    .then((data) => localStorage.setItem("service_token", data.token));
});

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you see a problem with using 'Authorization': Bearer ${jwt} with the token you store in service_token?
The idea is to get rid of the URL params with authorization data, as normally the URLs are logged in different places in the backend and is hard to sanitize, so its a better practice to use the headers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't see any problem doing this, as long as it works. Moreover it's cleaner. I'll let you know when the change will be done ;-)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use local storage like this:

room.join(jitsiLocalStorage.getItem('xmpp_conference_password_override'), replaceParticipant);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All good and retested!

params.append('query', query);
params.append('queryTypes', queryTypesString);
params.append('jwt', jwt);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not add jwt as URL param since: 9af0003


if (peopleSearchTokenLocation && peopleSearchTokenKey) {
const peopleSearchToken = localStorage.getItem(peopleSearchTokenLocation) ?? "";
params.append(peopleSearchTokenKey, peopleSearchToken);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here why don't you use Authorization': `Bearer?

@raphaelbadawi
Copy link
Contributor Author

Thank you for the quick review @damencho.

So first I will check all the linter errors today and make sure npm run lint passes.

As for the JWT in the headers, it was not there three months ago when I first did the PR. I just noticed the change today when remerging master to the branch, so I will update things consequently ;-)

I'll put a comment when everything will be settled.

@damencho
Copy link
Member

Yep, the changes were added a month later after the PR, sorry it fell trough the cracks.

@github-actions github-actions bot removed the stale label Jul 13, 2024
@raphaelbadawi
Copy link
Contributor Author

raphaelbadawi commented Jul 13, 2024

Hmm there is yet a little regression to fix I will let you know when everything is OK.

@raphaelbadawi
Copy link
Contributor Author

Everything has been retested again should be fine now. Thanks!

@raphaelbadawi
Copy link
Contributor Author

Up

const headers = {
...jwt ? { 'Authorization': `Bearer ${jwt}` } : {},
'Content-Type': 'application/json'
};

return fetch(
`${inviteServiceUrl}`,
`${inviteServiceUrl}?${params.toString()}`,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the default case there will be an empty ? at the end.

@damencho
Copy link
Member

Other than the questions I have and the small lint error LGTM.

@damencho
Copy link
Member

damencho commented Aug 1, 2024

@raphaelbadawi
Can you add // @ts-expect-error on the previous line before the js-utils import :) to fix the lint error

@damencho
Copy link
Member

damencho commented Aug 1, 2024

@raphaelbadawi Can you add // @ts-expect-error on the previous line before the js-utils import :) to fix the lint error

I did it. Let's see now 🤞

@damencho
Copy link
Member

damencho commented Aug 1, 2024

jenkins test this please.

@raphaelbadawi
Copy link
Contributor Author

@raphaelbadawi Can you add // @ts-expect-error on the previous line before the js-utils import :) to fix the lint error

I did it. Let's see now 🤞

Thank you, I didn't react quickly enough.

jenkins test this please.

Do I have to do something for this part?

@damencho
Copy link
Member

damencho commented Aug 1, 2024

Do I have to do something for this part?

Nope, these is triggering the integration tests when the PR creator is not one of the devs.

@damencho damencho merged commit 1e101af into jitsi:master Aug 1, 2024
9 checks passed
@damencho
Copy link
Member

damencho commented Aug 1, 2024

Thank you for your contribution and patience :)

@raphaelbadawi
Copy link
Contributor Author

Thank you for your contribution and patience :)

Thank you for your great insights ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants