Skip to content
This repository has been archived by the owner on Jun 7, 2020. It is now read-only.

[FIX] Enable support for Rocket hosted on subdirectory #1277

Merged
merged 8 commits into from
Mar 23, 2018

Conversation

jpowie01
Copy link
Contributor

@RocketChat/ios

Closes #900

These changes make sure that API Requests will follow HTTP protocol with applied subdirectory on which Rocket.Chat Server is hosted. Also, saves HTTP connection to the database instead of WebSocket one.

Note: It would be nice if anyone would like to check it out and even countinue work on this as I'm not familiar with Swift/iOS/Rocket.Chat.iOS at all. It's my proposal for changes :)

@CLAassistant
Copy link

CLAassistant commented Feb 16, 2018

CLA assistant check
All committers have signed the CLA.

Copy link
Collaborator

@cardoso cardoso left a comment

Choose a reason for hiding this comment

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

Thanks @jpowie01 !!

Let's see how we can fix this problem in the best way possible.

  1. What server are you using to test this? Is it public?
  2. I requested couple changes for now.

@@ -40,15 +40,15 @@ class API: APIFetcher {
var userId: String?

convenience init?(host: String, version: Version = .zero) {
guard let url = URL(string: host) else {
guard let url = URL(string: host)?.httpServerURL() else {
Copy link
Collaborator

Choose a reason for hiding this comment

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

We shouldn't make these changes here.

It would be better if we make this change where we are initializing the API object.

Take a look at APIExtensions.swift

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

return nil
}

self.init(host: url, version: version)
}

init(host: URL, version: Version = .zero) {
self.host = host
self.host = host.httpServerURL() ?? host
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same thing

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

@jpowie01
Copy link
Contributor Author

Yes, my server is publicly available but I wouldn't like to share a link here. I can send you an URL to my instance via email if you want to test it on your own. I'll try to resolve above comments today. Thanks! :)

@cardoso
Copy link
Collaborator

cardoso commented Feb 17, 2018

@jpowie01 Great! You can send me the link at https://open.rocket.chat/direct/matheus.cardoso


XCTAssertEqual(object.apiHost?.absoluteString, "https://team.rocket.chat/subdirectory/", "apiHost returns API Host correctly")
}

Choose a reason for hiding this comment

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

Trailing Whitespace Violation: Lines should not have trailing whitespace. (trailing_whitespace)


XCTAssertEqual(object.apiHost?.absoluteString, "https://team.rocket.chat/subdirectory/", "apiHost returns API Host correctly")
}

Choose a reason for hiding this comment

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

Trailing Whitespace Violation: Lines should not have trailing whitespace. (trailing_whitespace)


XCTAssertEqual(object.apiHost?.absoluteString, "https://team.rocket.chat/subdirectory/", "apiHost returns API Host correctly")
}

Choose a reason for hiding this comment

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

Trailing Whitespace Violation: Lines should not have trailing whitespace. (trailing_whitespace)

Copy link
Contributor

@rafaelks rafaelks left a comment

Choose a reason for hiding this comment

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

On my tests, the custom emojis of open.rocket.chat didn't load. Can you guys also reproduce the issue?

@jpowie01
Copy link
Contributor Author

You're right! Debugged, fixed & pushed to this PR :)

@rafaelks
Copy link
Contributor

@jpowie01 Tests aren't passing... can you take a look again please? I tried re-run the CI but still didn't pass.

@jpowie01
Copy link
Contributor Author

Could you help me guys with reproduction? All tests passes on my local machine. Here are logs from above test taken from Xcode:

Test Suite 'InfoClientSpec' started at 2018-02-27 23:04:12.555
Test Case '-[Rocket_ChatTests.InfoClientSpec testFetchInfo]' started.
[WebSocket] http upgrade response (HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: oV6ru9aDJyVARjY/Scpa+utZvdc=

)
[WebSocket] wss://open.rocket.chat/websocket
 -  did connect
[WebSocket] wss://open.rocket.chat/websocket
 -  will send message: {
  "version" : "1",
  "id" : "l1zIiojoKZfCgqK4AJDbeGsY3eBLlCb4hwMPvenndXYtDin78a",
  "support" : [
    "1",
    "pre2",
    "pre1"
  ],
  "msg" : "connect"
}
[WebSocket] wss://open.rocket.chat/websocket
 - did receive JSON message:
{
  "server_id" : "0"
}
Msg is invalid: {
  "server_id" : "0"
}
[WebSocket] wss://open.rocket.chat/websocket
 - did receive JSON message:
{
  "session" : "eSoTTYayYXu7mc3G7",
  "msg" : "connected"
}
[WebSocket] wss://open.rocket.chat/websocket
 -  will send message: {
  "id" : "FqadlQU4SBntoIkwWrQqz0GfDYYXl1H4IVS7hP8Pz3maA1BEFZ",
  "method" : "public-settings\/get",
  "msg" : "method"
}
[WebSocket] wss://open.rocket.chat/websocket
 - did receive JSON message:
{
  "methods" : [
    "FqadlQU4SBntoIkwWrQqz0GfDYYXl1H4IVS7hP8Pz3maA1BEFZ"
  ],
  "msg" : "updated"
}
Test Case '-[Rocket_ChatTests.InfoClientSpec testFetchInfo]' passed (1.143 seconds).

Am I right that I'm lucky it ends just before the deadline (1.1 second)? I rerun tests a couple of times and it just works:

Executed 325 tests, with 0 failures (0 unexpected) in 6.920 (7.390) seconds

My setup: Xcode Version 9.0.1 (9A1004).

@rafaelks
Copy link
Contributor

@cardoso The test is failing in a "wait()" method. Can you take a look please?

@cardoso
Copy link
Collaborator

cardoso commented Feb 28, 2018

It's most likely a random crash @rafaelks. I'll take a look.

@rafaelks
Copy link
Contributor

rafaelks commented Mar 2, 2018

@jpowie01 Just made some testing and looks like the loading of attachments doesn't work on servers with subdirectory.

Steps to reproduce:

  1. Authenticate in a server with subdirectory;
  2. Upload a file;
  3. The file won't show in your app;
  4. The fill will show on the web browser;

Can you fix this one also, please?

@jpowie01
Copy link
Contributor Author

jpowie01 commented Mar 4, 2018

Thanks for that! I'll look into this issue tomorrow. That's probably a problem with string concatenation instead of API usage for building URLs.

@rafaelks
Copy link
Contributor

rafaelks commented Mar 5, 2018

@jpowie01 Sure! Let me know when you're done, we're looking to merge this one for next release. 👍

@jpowie01
Copy link
Contributor Author

jpowie01 commented Mar 5, 2018

I've debugged it and... it's strange :/

iOS application points to this place if it would like to fetch an attachment (eg. an image):
https://{MY_INSTANCE}/{SUBDIR}/file-upload/{SOME_HASH}/{FILE_NAME}.jpeg

But... the file is actually available under this path:
https://{MY_INSTANCE}/{SUBDIR}/{SUBDIR}/file-upload/{SOME_HASH}/{FILE_NAME}

So... Sending attatchments in browser works because it points to a place with double subdirectory in path!

What's more - desktop (Mac) application points to a single subdirectory path (like an iOS app) which causes the same issues as described here.

Maybe my server settings are broken? But it would be strange as all other things seems to work like a charm. For me, it sounds like a bug on the server side... Do you have any other instance running on a subdirectory just for testing?

@rafaelks
Copy link
Contributor

rafaelks commented Mar 6, 2018

@jpowie01 Thanks for looking into it. Looks like there's a bug on upload. I'll try to investigate with the back-end guys to see what's going on.

@rafaelks
Copy link
Contributor

rafaelks commented Mar 6, 2018

@jpowie01 Yes, the issue is fixed already and will be released to next release: RocketChat/Rocket.Chat#10029.

I'll try your PR with this version of the server and I'm gonna merge it if that works fine.

Thank you!!!

@jpowie01
Copy link
Contributor Author

jpowie01 commented Mar 6, 2018

Cool, great! Thanks for confirmation! :)

@jpowie01
Copy link
Contributor Author

I've updated my server to use the latest version of Rocket.chat and it fixed issues with attachments :)

Copy link
Contributor

@rafaelks rafaelks left a comment

Choose a reason for hiding this comment

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

Looking good!!! Thank you!

@rafaelks rafaelks merged commit 57287a3 into RocketChat:develop Mar 23, 2018
@@ -58,7 +58,7 @@ extension APIRequest {

func request(for api: API, options: APIRequestOptions = .none) -> URLRequest? {
var components = URLComponents(url: api.host, resolvingAgainstBaseURL: false)
components?.path = path
components?.path += path
Copy link
Collaborator

@filipealva filipealva Mar 23, 2018

Choose a reason for hiding this comment

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

@RocketChat/ios Guys, this += has introduced a bug, because we specify our paths as the following: /api/v1/me, and if we concatenate this path with the default path of an URLComponents it will result in a duplicated initial slash as the following: //api/v1/me which makes the request invalid.

It took me a while to discover what was going on because the result it is generating is not even handled as an error by the app, so it generated confusing behaviors such as making the app stuck on an endless loading in the auth screen, or even authenticating the user with a nil user 🕵️

Copy link
Collaborator

Choose a reason for hiding this comment

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

#1415 fixes it

Copy link
Contributor

Choose a reason for hiding this comment

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

@filipealva Thank you! 👍

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

Successfully merging this pull request may close these issues.

6 participants