-
Notifications
You must be signed in to change notification settings - Fork 26
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
Add jwt tests #714
Add jwt tests #714
Conversation
94e08ba
to
560ae07
Compare
Rebased on master. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few small comments, but mostly looks good to me 👍
Spec/Auth.swift
Outdated
@@ -3619,5 +3619,7 @@ class Auth : QuickSpec { | |||
} | |||
} | |||
} | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is going on here with the two extra closing squigglies?
Spec/TestUtilities.swift
Outdated
@@ -43,6 +43,7 @@ let appSetupJson = JSON(parseJSON: try! String(contentsOfFile: pathForTestResour | |||
|
|||
let testTimeout: TimeInterval = 10.0 | |||
let testResourcesPath = "ably-common/test-resources/" | |||
let echoServerAddress = "https://shrouded-plains-50367.herokuapp.com/createJWT" // TODO: change this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can just deploy your changes to the Heroku echoserver, even if not fully merged, to avoid having to go back and do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just didn't want to disrupt existing stuff that currently depends on the echo server. Happy to change this when the echo server PR is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But your changes aren’t breaking changes? You only added a new endpoint so I don’t see the risk personally
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only potential issue could be https://github.com/ably/echoserver/pull/4/commits/49a3a0f8af59a02a18f0c36451c958cfcf6224d0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@funkyboy why would that be an issue? I appreciate it's an upgrade, but you have run a full test suite against the echoServer running the new Node without any issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. Will do that with the Ruby SDK. If everything passes can I deploy then to echo.ably.io ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ran the full test suite of Ruby against the echo server in staging. All green: https://travis-ci.org/ably/ably-ruby/builds/388329095
Will promote it to production if there are no objections.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Spec/TestUtilities.swift
Outdated
@@ -494,6 +495,52 @@ func getTestTokenDetails(key: String? = nil, clientId: String? = nil, capability | |||
return tokenDetails | |||
} | |||
|
|||
func encodeString(_ input: String) -> String? { | |||
let allowedQueryParamAndKey = CharacterSet(charactersIn: "{}[]*: ") | |||
if let encodedString_ = input.addingPercentEncoding(withAllowedCharacters: allowedQueryParamAndKey) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indentation issues again
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually it was a leftover :) 54c84de
Spec/TestUtilities.swift
Outdated
keySecret = "invalid" | ||
} | ||
|
||
var URLCcomponents = URLComponents(string: echoServerAddress) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo I think, URLCcomponents
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, thanks. 903bc3e
Spec/Auth.swift
Outdated
|
||
it("pulls stats successfully") { | ||
waitUntil(timeout: testTimeout) { done in | ||
client.stats{ stats, error in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing whitespace after stats
I believe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. See a2100f2
Spec/Auth.swift
Outdated
|
||
it("fetches a channels and posts a message") { | ||
client.channels.get(channelName).publish(messageName, data: nil, callback: { error in | ||
expect(error).to(beNil()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the other tests test are wrapped in a waitUntil
with a call to done()
. How does the test suite know when this test is done?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good observation. c7efe08
Spec/Auth.swift
Outdated
it ("receives a 40142 error from the server") { | ||
waitUntil(timeout: testTimeout) { done in | ||
client.connection.once(.connected) { stateChange in | ||
delay(tokenDuration + 1) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you need this delay? Should the connection once(.disconnected)
fire below anyway once the token has expired? In fact, if waits tokenDuration
, what's probably happening with this test is that it's being disconnected once here, and once again below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done 936955b
|
||
it("fails to connect") { | ||
waitUntil(timeout: testTimeout) { done in | ||
client.connection.once(.failed) { stateChange in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we had agreed that https://docs.ably.io/client-lib-development-guide/features/#RSA4b stated that the connection should not become failed, but instead should become disconnected and retry. I believe @paddybyers updated the spec after chatting with you about this at some point, although oddly I can't find a matching commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add this as a TODO above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mattheworiordan RSA4b says that a REST request fails if a token error is returned after a retry, which is correct, and is unrelated to this test.
https://docs.ably.io/client-lib-development-guide/features/#RTN14b relates to token failures on connection creation - it says that a connection should not fail in that case, but become disconnected. This test is therefore wrong and, because it passes, there is also a bug in the library (which will have existed before these JWT changes). @funkyboy pls raise a separate issue for that (and find the other existing, non-JWT, invalid test).
The discussion you remembered related was https://github.com/ably/docs/issues/429, relating to RTN15h, and that's to do with failures to reconnect (ie not initial connection failures). I'm guessing that there's going to be an issue for iOS there as well. I will do a docs PR for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@paddybyers @mattheworiordan The non-JWT corresponding test is https://github.com/ably/ably-ios/blob/develop/Spec/Auth.swift#L305 and again it tests for FAILED
.
Issue raised here: #730
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will do a docs PR for that.
ably/docs#439. @funkyboy can you check that behaviour please in this library and see if complies with the DISCONNECTED
or FAILED
behaviour?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@paddybyers This seems to test the new RTN15h1
that you wrote.
These all riff around the same "token expired/wrong" conditions but none seems to tests for the "single attempt to renew the token" clause.
Should I open a new issue about this?
UPDATE: this seems close to test this https://github.com/ably/docs/pull/439/files#diff-11900b395df266bc2bbfc1d11bdfc7a0R390 but it's not checking for the connection state :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mattheworiordan RSA4b says that a REST request fails if a token error is returned after a retry, which is correct, and is unrelated to this test.
Oops, I should have scrolled up to see the context of the test I found. That explains why I could not find the record of the change we made in the spec!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ably/docs#439. @funkyboy can you check that behaviour please in this library and see if complies with the DISCONNECTED or FAILED behaviour?
Opened issue here #731
Spec/Auth.swift
Outdated
let clientId = "JWTClientId" | ||
let options = AblyTests.clientOptions() | ||
options.tokenDetails = ARTTokenDetails(token: getJWTToken(clientId: clientId)!) | ||
options.autoConnect = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More autoConnect
false although not sure why.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done 4b5ada4
Spec/Auth.swift
Outdated
} | ||
|
||
// RSA4f, RSA8c | ||
context("when the JWT token is returned with application/jwt content tye") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small typo, type
not tye
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
66aaad8
to
ab572c4
Compare
@paddybyers @mattheworiordan @ricardopereira ready for another look |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks
Fix ably/docs#713
authURL
ClientOptions
authCallback
x-ably-token
x-ably-capability
application/jwt
content typeauth_url
when echo server is deployed. See TODOs