This prevents joining the room for a file shared by link and protected
by password if the password has not been entered yet.
Signed-off-by: Joas Schilling <coding@schilljs.com>
Until now file rooms were available only to users with direct access to
the file. Now file rooms are available to any user or guest too if the
link is publicly shared (with a link share, for example).
Public shares are identified by a share token instead of a file id, so a
new endpoint, which is a counterpart of FilesController but for share
tokens, was added. The file room, however, is still associated to the
file id like before.
When checking if a participant can join a room if the current user is a
user without direct access to the file or a guest it is not even
possible to know if the file id belongs to a publicly shared file. Due
to this when the room is got for a share token the share token is stored
in the session and then used in following requests when checking whether
the participant can join a room or not.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This false set the read marker on new messages although you
navigated away to a different chat already. So we removed this
and instead update the read marker before your next waiting.
So when you are still there, it will just have a wrong read
marker for the time until your next request starts, while it will
not update the value, when you actually left the chat already.
Signed-off-by: Joas Schilling <coding@schilljs.com>
The lobby constants were named from the point of view of the webinary
(open to all participants, open to moderators only), but from the point
of view of the lobby it is the opposite (no lobby, lobby for non
moderators).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This fixes the code so it behaves as stated in the documentation.
In practice currently this should make no difference, as in the Files
app the user joins the room immediately after getting its token;
however, this makes possible to get the token without joining the room,
which will be needed in the future to improve the UX of the Files app.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Talk no longer uses JavaScript "eval", so the Content Security Policy
can now be configured to prevent its use.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
It could happen that an old session id expired while a user already re-joined
a room with a new session id. Once the old session id expired, the user got
removed from the room.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
When a user requests the signaling messages from the internal signaling
server first the last ping of the user is updated. Then, after waiting
for at most 30 seconds, the list of users active in the room is
returned.
That list was based on the users whose last ping happened around 30
seconds ago or less (it could be a bit longer than 30 seconds, but the
described problem remains in that case too); if other user pulled the
messages slightly before the current user and that other user did not
pull the messages again (or the chat messages, as that updates the last
ping too) before the user list was returned that other user was not
included in the list, as her last ping happened more than 30 seconds
ago.
Now the elapsed time since the last ping for users returned in the list
is longer than the timeout used for pulling messages (and chat messages)
to ensure (up to a point) that active users will be included in the list
even if it took a bit longer for them to pull messages again.
The drawback of this approach is that the internal signaling server will
now need a few more seconds to notice when a user left a call abruptly,
but before it was not immediate anyway and it should not be a common
scenario either.
Finally, note that it is unlikely that more than 40 seconds pass between
the ping is updated for the current user and the user list is returned,
but the condition to handle that case gracefully was kept to be on the
safe side.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a user requests the signaling messages from the internal signaling
server first the last ping of the user is updated. Then, after waiting
for at most 30 seconds, the list of users active in the room is
returned.
That list was based on the users whose last ping was more recent than 30
seconds ago, so when there were no other messages and the waiting timed
out the last ping of the current user set when the request started
happened 30 seconds ago or more, and thus the current user was not
included in the returned list (unless her ping was updated to a more
recent value by a different request, like polling for chat messages).
Now the users returned in the list are those whose last ping is more
recent than or equal to 30 seconds, or more recent than or equal to the
signaling ping of the current user if it is larger than 30 seconds.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the file is in a shared folder and the file is not explicitly
shared the first share found is not for the file, but for the folder. In
that case the file needs to be searched in the shared folder to get the
proper name for the room.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before a file was seen as directly accessible by the user if the user
received the file through a user, group, circle or room share. Now files
that are a descendant of a folder that meets those conditions are seen
as directly accessible by the user too.
Due to this now the rooms for files in a shared folder can be accessed
by any user that has access to the folder; it is no longer needed to
explicitly share the file too with them.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This allows for showing if user is online or not in the conversation info list without needing another API call
Signed-off-by: Mario Danic <mario@lovelyhq.com>
Until now only the e-mail shares had support for sending the password by
Talk. In Nextcloud 15 that feature was added to link shares too, so the
room name and the notification sent for "share:password" rooms has to be
adjusted accordingly.
The display name of "share:password" rooms is generated from the raw
name of the room (the e-mail for mail shares and the file name for link
shares) each time the room information is sent by the server, so the
display name was generalized to accomodate both types of raw names.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Joas Schilling
Daniel Calviño Sánchez
Joas Schilling
Ivan Sein
Ivan Sein
Joachim Bauch
Peter Edens
Mario Danic