When the public share page is loaded "publicshare.js" is initialized,
which modifies the page to add a Talk sidebar. The default layout has
the header, content and footer in a flex column; when the sidebar is
added the layout id modified to still have the header and content in a
flex column, but the content is now a flex row that includes
"#app-content" and the sidebar, and the footer is moved inside
"#app-content" so it does not affect the sidebar.
The Talk sidebar includes a call container at the top, which is only
shown during calls, and below it a call button and a chat view which are
always shown.
The CSS styles are a mix of the styles for the public share auth page
and the Files app, as well as some rules copied from the main
"style.scss" file.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The default Content Security Policy restricts connections only to the
same domain of the page, so the domains of the web sockets used to
connect to the standalone signaling servers must be explicitly allowed.
This has to be done for Nextcloud as a whole, as Talk is embedded in
other apps by loading additional scripts in the browser, and thus it is
not possible to set the Content Security Policy in the controllers that
serve those apps.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This is just a workaround that fixes#1408, the cleaner solution should be
to get the list of session ids from the event and pass it along to the
signaling server.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
Note, however, that the participant will never receive that message from
the signaling endpoint, but a 404 error due to the room no longer
existing. In any case, this ends the pending signaling request as soon
as the room is deleted instead of keep waiting until the timeout ends.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a participant is removed or disconnected from a room the
"refresh-participant-list" signaling message is added to all the
participants in that room. However, the participant just removed or
disconnected is no longer in the room, so the message needs to be
explicitly added for that participant.
Note, however, that the participant will never receive that message from
the signaling endpoint, but a 404 error due to no longer being in the
room. In any case, this ends the pending signaling request as soon as
the participant is removed or disconnected instead of keep waiting until
the timeout ends.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This commit introduces a DetailTabView plugin to show a chat view in the
sidebar of the Files app. The tab makes possible to chat in a Talk room
associated to the current file; due to this, the tab is visible only on
files that can be associated to a room, that is, files shared with the
current user or by the current user to another user (as a user, group,
circle...).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The rooms associated to a file are public rooms, so anyone could join
them provided she knows its token. Thus, now it is enforced that only
participants with direct access to the file can join the room.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a user is removed from a room by any means all the shares owned and
received by that user are removed.
When a room is deleted all the shares in that room are deleted.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before the public share auth page is rendered an event is dispatched
that can be used by apps to load additional scripts. This event is now
used to load the scripts that, when run on the browser, will inject the
Talk UI as needed in the page generated by the server.
The scripts will be loaded only when the share has the "send password by
Talk" option enabled; they add a button to the page that, when pressed,
creates a new public share auth room with the sharer and shows, in a
sidebar, the Talk UI for that room.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The rooms to request the password for a share are public rooms, so
anyone could join them provided she knows its token. Thus, now it is
enforced that only a single participant besides the owner can join the
room.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Due to their nature there is no point in keeping a room to request the
password of a share once any of the participants has left, so they are
automatically destroyed in that case.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>