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

[NEW] Add JWT to uploaded files urls #15297

Merged
merged 16 commits into from
Sep 17, 2019
Merged

Conversation

MarcosSpessatto
Copy link
Contributor

No description provided.

@MarcosSpessatto MarcosSpessatto added this to the 2.1.0 milestone Sep 3, 2019
@MarcosSpessatto MarcosSpessatto changed the title [NEW] Add JWT to uploaded files urls [WIP][NEW] Add JWT to uploaded files urls Sep 3, 2019
@MarcosSpessatto MarcosSpessatto changed the title [WIP][NEW] Add JWT to uploaded files urls [NEW] Add JWT to uploaded files urls Sep 4, 2019
@RocketChat RocketChat deleted a comment from lgtm-com bot Sep 4, 2019
Copy link

@renatobecker-zz renatobecker-zz left a comment

Choose a reason for hiding this comment

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

My suggestion is to create a method/property to get the file path from the FileUpload store, instead of testing the file system outside the FileUpload instance.

Copy link

@renatobecker-zz renatobecker-zz left a comment

Choose a reason for hiding this comment

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

@MarcosSpessatto, I left some comments on your PR. They're just improvements on the codebase, but in my opinion, it would uncouple the process of adding the JWT token to the URL.

@@ -294,6 +295,7 @@ export const FileUpload = {
}

let { rc_uid, rc_token, rc_rid, rc_room_type } = query;
const { jwt } = query;

Choose a reason for hiding this comment

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

What about renaming the query parameter to token?

@@ -23,6 +23,7 @@ import { roomTypes } from '../../../utils/server/lib/roomTypes';
import { hasPermission } from '../../../authorization/server/functions/hasPermission';
import { canAccessRoom } from '../../../authorization/server/functions/canAccessRoom';
import { fileUploadIsValidContentType } from '../../../utils/lib/fileUploadRestrictions';
import { isValidJWT, generateJsonWebToken } from '../../../utils/server/lib/JWTHelper';

Choose a reason for hiding this comment

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

What do you think of renaming to generateJWT, just like the same pattern on the isValidJWT ?

@@ -389,6 +392,29 @@ export const FileUpload = {

request.get(fileUrl, (fileRes) => fileRes.pipe(res));
},

addJWTToFileUrlIfNecessary(message) {

Choose a reason for hiding this comment

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

IMHO, we should check the file field outside this method. I mean, to me it looks weird returning a message from a method that deals with JWT stuff.

So, then the method will return the JWT itself, not a message object.

fileId: message.file._id,
}, settings.get('FileUpload_json_web_token_secret_for_files'));

if (message.attachments && Array.isArray(message.attachments) && message.attachments.length) {

Choose a reason for hiding this comment

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

...and this code looks to be a good helper method which would return the message object.

@@ -95,7 +96,7 @@ API.v1.addRoute('livechat/message/:_id', {
throw new Meteor.Error('invalid-message');
}

return API.v1.success({ message });
return API.v1.success({ message: FileUpload.addJWTToFileUrlIfNecessary(message) });

Choose a reason for hiding this comment

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

As I commented before, IMO it would be better having a specific helper method to handle this process, and inside that method, I would call the addJWTToFileUrlIfNecessary method.
In that case, we could rename the addJWTToFileUrlIfNecessary to addJWTToFileUrl.

@@ -33,6 +34,8 @@ callbacks.add('afterSaveMessage', function(message, room) {
return message;
}

message = FileUpload.addJWTToFileUrlIfNecessary(message);

Choose a reason for hiding this comment

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

As I commented before, IMO it would be better having a specific helper method to handle this process, and inside that method, I would call the addJWTToFileUrlIfNecessary method.
In that case, we could rename the addJWTToFileUrlIfNecessary to addJWTToFileUrl.

@@ -12,6 +13,8 @@ callbacks.add('afterSaveMessage', function(message, room) {
return message;
}

message = FileUpload.addJWTToFileUrlIfNecessary(message);

Choose a reason for hiding this comment

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

As I commented before, IMO it would be better having a specific helper method to handle this process, and inside that method, I would call the addJWTToFileUrlIfNecessary method.
In that case, we could rename the addJWTToFileUrlIfNecessary to addJWTToFileUrl.

@@ -54,8 +55,7 @@ function sendToCRM(type, room, includeMessages = true) {
if (message.t === msgNavType) {
msg.navigation = message.navigation;
}

postData.messages.push(msg);
postData.messages.push(message.file ? FileUpload.addJWTToFileUrlIfNecessary(message) : msg);

Choose a reason for hiding this comment

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

As I commented before, IMO it would be better having a specific helper method to handle this process, and inside that method, I would call the addJWTToFileUrlIfNecessary method.
In that case, we could rename the addJWTToFileUrlIfNecessary to addJWTToFileUrl.

@@ -16,6 +17,7 @@ callbacks.add('afterSaveMessage', function(message, room) {
if (!(typeof room.t !== 'undefined' && room.t === 'l' && room.facebook && room.v && room.v.token)) {
return message;
}
FileUpload.addJWTToFileUrlIfNecessary(message);

Choose a reason for hiding this comment

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

As I commented before, IMO it would be better having a specific helper method to handle this process, and inside that method, I would call the addJWTToFileUrlIfNecessary method.
In that case, we could rename the addJWTToFileUrlIfNecessary to addJWTToFileUrl.

@@ -18,6 +19,8 @@ callbacks.add('afterSaveMessage', function(message, room) {
return message;
}

FileUpload.addJWTToFileUrlIfNecessary(message);

Choose a reason for hiding this comment

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

As I commented before, IMO it would be better having a specific helper method to handle this process, and inside that method, I would call the addJWTToFileUrlIfNecessary method.
In that case, we could rename the addJWTToFileUrlIfNecessary to addJWTToFileUrl.

@renatobecker-zz renatobecker-zz added this to In progress in Omnichannel Roadmap via automation Sep 10, 2019
Omnichannel Roadmap automation moved this from In progress to Needs review Sep 11, 2019
@@ -95,7 +96,7 @@ API.v1.addRoute('livechat/message/:_id', {
throw new Meteor.Error('invalid-message');
}

return API.v1.success({ message });
return API.v1.success({ message: normalizeMessageAttachments(message) });
} catch (e) {
return API.v1.failure(e.error);

Choose a reason for hiding this comment

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

Suggested change
return API.v1.failure(e.error);
return API.v1.failure(e);

const messages = loadMessageHistory({ userId: guest._id, rid, end, limit, ls });
const messages = loadMessageHistory({ userId: guest._id, rid, end, limit, ls })
.messages
.map(normalizeMessageAttachments);
return API.v1.success(messages);
} catch (e) {
return API.v1.failure(e.error);

Choose a reason for hiding this comment

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

Suggested change
return API.v1.failure(e.error);
return API.v1.failure(e);

@@ -227,7 +228,9 @@ API.v1.addRoute('livechat/messages.history/:rid', {
limit = parseInt(this.queryParams.limit);
}

const messages = loadMessageHistory({ userId: guest._id, rid, end, limit, ls });
const messages = loadMessageHistory({ userId: guest._id, rid, end, limit, ls })

Choose a reason for hiding this comment

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

The new implementation is returning an array of messages, but the original implementation needs to return an object containing a property called by messages, which will contain the array of messages.


export const normalizeMessageAttachments = (message) => {
if (message.file && message.attachments && Array.isArray(message.attachments) && message.attachments.length) {
const jwt = FileUpload.addJWTToFileUrl({ rid: message.rid, userId: message.u._id, fileId: message.file._id });

Choose a reason for hiding this comment

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

Since the FileUpload.addJWTToFileUrl may return null, you need to check the returned value before moving forward, don't you think?

Thanks.

@@ -95,9 +96,9 @@ API.v1.addRoute('livechat/message/:_id', {
throw new Meteor.Error('invalid-message');
}

return API.v1.success({ message });
return API.v1.success({ message: normalizeMessageAttachments(message) });

Choose a reason for hiding this comment

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

Do you mind of checking the message.file before returning? I think we should always return the message instead of the normalizeMessageAttachments.

@@ -134,12 +135,12 @@ API.v1.addRoute('livechat/message/:_id', {
const result = Livechat.updateMessage({ guest, message: { _id: msg._id, msg: this.bodyParams.msg } });
if (result) {
const message = Messages.findOneById(_id);
return API.v1.success({ message });
return API.v1.success({ message: normalizeMessageAttachments(message) });

Choose a reason for hiding this comment

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

Do you mind of checking the message.file before returning? I think we should always return the message instead of the normalizeMessageAttachments.

@@ -33,6 +34,8 @@ callbacks.add('afterSaveMessage', function(message, room) {
return message;
}

message = normalizeMessageAttachments(message);

Choose a reason for hiding this comment

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

Do you mind of checking the message.file before returning? I think we should always return the message instead of the normalizeMessageAttachments.

postData.messages.push(msg);
if (message.file) {
msg.file = message.file;
msg.attachments = message.attachments;

Choose a reason for hiding this comment

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

Why not call the normalizer function inside this block of code?

@@ -33,5 +34,5 @@ callbacks.add('afterSaveMessage', function(message, room) {
text: message.msg,
});

return message;
return normalizeMessageAttachments(message);

Choose a reason for hiding this comment

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

Do you mind of checking the message.file before returning? I think we should always return the message instead of the normalizeMessageAttachments.

@@ -42,5 +43,5 @@ callbacks.add('afterSaveMessage', function(message, room) {

SMSService.send(room.sms.from, visitor.phone[0].phoneNumber, message.msg);

return message;
return normalizeMessageAttachments(message);

Choose a reason for hiding this comment

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

Do you mind of checking the message.file before returning? I think we should always return the message instead of the normalizeMessageAttachments.

Omnichannel Roadmap automation moved this from Needs review to Reviewer approved Sep 12, 2019
@renatobecker-zz renatobecker-zz merged commit bb61341 into develop Sep 17, 2019
Omnichannel Roadmap automation moved this from Reviewer approved to Done Sep 17, 2019
@renatobecker-zz renatobecker-zz deleted the add-jwt-to-file-upload-urls branch September 17, 2019 13:33
@sampaiodiego sampaiodiego mentioned this pull request Sep 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

None yet

4 participants