How should one handle NSURLAuthenticationMethodXMobileMeAuthToken?
We're using a NSURLSessionDataDelegate and have the following delegate method implemented:
- (void) URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler { ... }
Frequently we find that users of iCloud receive a NSURLAuthenticationMethodXMobileMeAuthToken challenge. Sending back a rejection doesn't work (as the server won't try another challenge) and sending back an acceptance with
completionHandler(NSURLSessionAuthChallengeUseCredential, credential);
doesn't work either.
What are we supposed to do with this authentication challenge type? Has anyone else seen it?
cocoa icloud nsurlsession
asked Nov 13 '18 at 18:47
strangetimesstrangetimes
1,86411441
add a comment |
We're using a NSURLSessionDataDelegate and have the following delegate method implemented:
- (void) URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler { ... }
Frequently we find that users of iCloud receive a NSURLAuthenticationMethodXMobileMeAuthToken challenge. Sending back a rejection doesn't work (as the server won't try another challenge) and sending back an acceptance with
completionHandler(NSURLSessionAuthChallengeUseCredential, credential);
doesn't work either.
What are we supposed to do with this authentication challenge type? Has anyone else seen it?
cocoa icloud nsurlsession
asked Nov 13 '18 at 18:47
strangetimesstrangetimes
1,86411441
What's the protectionSpace associated with these calls look like?
– Dad
Nov 20 '18 at 4:47
Have you tried calling the completion handler with NSURLSessionAuthChallengePerformDefaultHandling and nil for credential?
– Dad
Nov 20 '18 at 4:48
How about with NSURLSessionAuthChallengeRejectProtectionSpace and nil for the credential? If so, does your delegate should get called again with the next authentication projection space?
– Dad
Nov 20 '18 at 4:48
add a comment |
We're using a NSURLSessionDataDelegate and have the following delegate method implemented:
- (void) URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler { ... }
Frequently we find that users of iCloud receive a NSURLAuthenticationMethodXMobileMeAuthToken challenge. Sending back a rejection doesn't work (as the server won't try another challenge) and sending back an acceptance with
completionHandler(NSURLSessionAuthChallengeUseCredential, credential);
doesn't work either.
What are we supposed to do with this authentication challenge type? Has anyone else seen it?
cocoa icloud nsurlsession
asked Nov 13 '18 at 18:47
strangetimesstrangetimes
1,86411441
We're using a NSURLSessionDataDelegate and have the following delegate method implemented:
- (void) URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler { ... }
Frequently we find that users of iCloud receive a NSURLAuthenticationMethodXMobileMeAuthToken challenge. Sending back a rejection doesn't work (as the server won't try another challenge) and sending back an acceptance with
completionHandler(NSURLSessionAuthChallengeUseCredential, credential);
doesn't work either.
What are we supposed to do with this authentication challenge type? Has anyone else seen it?
cocoa icloud nsurlsession
cocoa icloud nsurlsession
asked Nov 13 '18 at 18:47
strangetimesstrangetimes
1,86411441
asked Nov 13 '18 at 18:47
strangetimesstrangetimes
1,86411441
asked Nov 13 '18 at 18:47
strangetimesstrangetimes
1,86411441
asked Nov 13 '18 at 18:47
strangetimesstrangetimes
1,86411441
asked Nov 13 '18 at 18:47
strangetimesstrangetimes
1,86411441
1,86411441
What's the protectionSpace associated with these calls look like?
– Dad
Nov 20 '18 at 4:47
Have you tried calling the completion handler with NSURLSessionAuthChallengePerformDefaultHandling and nil for credential?
– Dad
Nov 20 '18 at 4:48
How about with NSURLSessionAuthChallengeRejectProtectionSpace and nil for the credential? If so, does your delegate should get called again with the next authentication projection space?
– Dad
Nov 20 '18 at 4:48
add a comment |
What's the protectionSpace associated with these calls look like?
– Dad
Nov 20 '18 at 4:47
Have you tried calling the completion handler with NSURLSessionAuthChallengePerformDefaultHandling and nil for credential?
– Dad
Nov 20 '18 at 4:48
How about with NSURLSessionAuthChallengeRejectProtectionSpace and nil for the credential? If so, does your delegate should get called again with the next authentication projection space?
– Dad
Nov 20 '18 at 4:48
What's the protectionSpace associated with these calls look like?
– Dad
Nov 20 '18 at 4:47
What's the protectionSpace associated with these calls look like?
– Dad
Nov 20 '18 at 4:47
Have you tried calling the completion handler with NSURLSessionAuthChallengePerformDefaultHandling and nil for credential?
– Dad
Nov 20 '18 at 4:48
Have you tried calling the completion handler with NSURLSessionAuthChallengePerformDefaultHandling and nil for credential?
– Dad
Nov 20 '18 at 4:48
How about with NSURLSessionAuthChallengeRejectProtectionSpace and nil for the credential? If so, does your delegate should get called again with the next authentication projection space?
– Dad
Nov 20 '18 at 4:48
How about with NSURLSessionAuthChallengeRejectProtectionSpace and nil for the credential? If so, does your delegate should get called again with the next authentication projection space?
– Dad
Nov 20 '18 at 4:48
add a comment |
1 Answer
1
active
oldest
votes
For any protection space that you aren't explicitly handling, or for any credential type that you don't understand, you should typically use NSURLSessionAuthChallengePerformDefaultHandling (the credential is ignored, but typically pass nil) to tell the OS to handle the credential as though you didn't provide an authentication delegate method.
answered Dec 2 '18 at 5:15
dgatwooddgatwood
8,09012042
The trouble is - I've tried every combination of this and anything else, but it won't go away. Just recently though, I think I know what this might be. Essentially the "authorisation" header may have been missing from the request due to a re-direct, and so when that isn't there, iCloud sends a MobileMe token auth challenge and nothing else. Intercepting re-directs and then adding an authorisation header back in again seems to have 'fixed' this.
– strangetimes
Dec 2 '18 at 11:57
What servers are you hitting?
– dgatwood
Dec 2 '18 at 16:44
cadav.icloud.com
– strangetimes
Dec 2 '18 at 16:44
Ah. Now that makes sense. I assume you're manually injecting an auth header during the initial request? Then yes, the right solution is to also alter theNSURLRequestwhenever you get a redirect, to ensure that the auth header is also included in those.
– dgatwood
Dec 3 '18 at 5:05
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53287653%2fhow-should-one-handle-nsurlauthenticationmethodxmobilemeauthtoken%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
For any protection space that you aren't explicitly handling, or for any credential type that you don't understand, you should typically use NSURLSessionAuthChallengePerformDefaultHandling (the credential is ignored, but typically pass nil) to tell the OS to handle the credential as though you didn't provide an authentication delegate method.
answered Dec 2 '18 at 5:15
dgatwooddgatwood
8,09012042
The trouble is - I've tried every combination of this and anything else, but it won't go away. Just recently though, I think I know what this might be. Essentially the "authorisation" header may have been missing from the request due to a re-direct, and so when that isn't there, iCloud sends a MobileMe token auth challenge and nothing else. Intercepting re-directs and then adding an authorisation header back in again seems to have 'fixed' this.
– strangetimes
Dec 2 '18 at 11:57
What servers are you hitting?
– dgatwood
Dec 2 '18 at 16:44
cadav.icloud.com
– strangetimes
Dec 2 '18 at 16:44
Ah. Now that makes sense. I assume you're manually injecting an auth header during the initial request? Then yes, the right solution is to also alter theNSURLRequestwhenever you get a redirect, to ensure that the auth header is also included in those.
– dgatwood
Dec 3 '18 at 5:05
add a comment |
For any protection space that you aren't explicitly handling, or for any credential type that you don't understand, you should typically use NSURLSessionAuthChallengePerformDefaultHandling (the credential is ignored, but typically pass nil) to tell the OS to handle the credential as though you didn't provide an authentication delegate method.
answered Dec 2 '18 at 5:15
dgatwooddgatwood
8,09012042
The trouble is - I've tried every combination of this and anything else, but it won't go away. Just recently though, I think I know what this might be. Essentially the "authorisation" header may have been missing from the request due to a re-direct, and so when that isn't there, iCloud sends a MobileMe token auth challenge and nothing else. Intercepting re-directs and then adding an authorisation header back in again seems to have 'fixed' this.
– strangetimes
Dec 2 '18 at 11:57
What servers are you hitting?
– dgatwood
Dec 2 '18 at 16:44
cadav.icloud.com
– strangetimes
Dec 2 '18 at 16:44
Ah. Now that makes sense. I assume you're manually injecting an auth header during the initial request? Then yes, the right solution is to also alter theNSURLRequestwhenever you get a redirect, to ensure that the auth header is also included in those.
– dgatwood
Dec 3 '18 at 5:05
add a comment |
For any protection space that you aren't explicitly handling, or for any credential type that you don't understand, you should typically use NSURLSessionAuthChallengePerformDefaultHandling (the credential is ignored, but typically pass nil) to tell the OS to handle the credential as though you didn't provide an authentication delegate method.
answered Dec 2 '18 at 5:15
dgatwooddgatwood
8,09012042
For any protection space that you aren't explicitly handling, or for any credential type that you don't understand, you should typically use NSURLSessionAuthChallengePerformDefaultHandling (the credential is ignored, but typically pass nil) to tell the OS to handle the credential as though you didn't provide an authentication delegate method.
answered Dec 2 '18 at 5:15
dgatwooddgatwood
8,09012042
answered Dec 2 '18 at 5:15
dgatwooddgatwood
8,09012042
answered Dec 2 '18 at 5:15
dgatwooddgatwood
8,09012042
answered Dec 2 '18 at 5:15
dgatwooddgatwood
8,09012042
8,09012042
The trouble is - I've tried every combination of this and anything else, but it won't go away. Just recently though, I think I know what this might be. Essentially the "authorisation" header may have been missing from the request due to a re-direct, and so when that isn't there, iCloud sends a MobileMe token auth challenge and nothing else. Intercepting re-directs and then adding an authorisation header back in again seems to have 'fixed' this.
– strangetimes
Dec 2 '18 at 11:57
What servers are you hitting?
– dgatwood
Dec 2 '18 at 16:44
cadav.icloud.com
– strangetimes
Dec 2 '18 at 16:44
Ah. Now that makes sense. I assume you're manually injecting an auth header during the initial request? Then yes, the right solution is to also alter theNSURLRequestwhenever you get a redirect, to ensure that the auth header is also included in those.
– dgatwood
Dec 3 '18 at 5:05
add a comment |
The trouble is - I've tried every combination of this and anything else, but it won't go away. Just recently though, I think I know what this might be. Essentially the "authorisation" header may have been missing from the request due to a re-direct, and so when that isn't there, iCloud sends a MobileMe token auth challenge and nothing else. Intercepting re-directs and then adding an authorisation header back in again seems to have 'fixed' this.
– strangetimes
Dec 2 '18 at 11:57
What servers are you hitting?
– dgatwood
Dec 2 '18 at 16:44
cadav.icloud.com
– strangetimes
Dec 2 '18 at 16:44
Ah. Now that makes sense. I assume you're manually injecting an auth header during the initial request? Then yes, the right solution is to also alter theNSURLRequestwhenever you get a redirect, to ensure that the auth header is also included in those.
– dgatwood
Dec 3 '18 at 5:05
The trouble is - I've tried every combination of this and anything else, but it won't go away. Just recently though, I think I know what this might be. Essentially the "authorisation" header may have been missing from the request due to a re-direct, and so when that isn't there, iCloud sends a MobileMe token auth challenge and nothing else. Intercepting re-directs and then adding an authorisation header back in again seems to have 'fixed' this.
– strangetimes
Dec 2 '18 at 11:57
The trouble is - I've tried every combination of this and anything else, but it won't go away. Just recently though, I think I know what this might be. Essentially the "authorisation" header may have been missing from the request due to a re-direct, and so when that isn't there, iCloud sends a MobileMe token auth challenge and nothing else. Intercepting re-directs and then adding an authorisation header back in again seems to have 'fixed' this.
– strangetimes
Dec 2 '18 at 11:57
What servers are you hitting?
– dgatwood
Dec 2 '18 at 16:44
What servers are you hitting?
– dgatwood
Dec 2 '18 at 16:44
cadav.icloud.com
– strangetimes
Dec 2 '18 at 16:44
cadav.icloud.com
– strangetimes
Dec 2 '18 at 16:44
Ah. Now that makes sense. I assume you're manually injecting an auth header during the initial request? Then yes, the right solution is to also alter the
NSURLRequest whenever you get a redirect, to ensure that the auth header is also included in those.– dgatwood
Dec 3 '18 at 5:05
Ah. Now that makes sense. I assume you're manually injecting an auth header during the initial request? Then yes, the right solution is to also alter the
NSURLRequest whenever you get a redirect, to ensure that the auth header is also included in those.– dgatwood
Dec 3 '18 at 5:05
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53287653%2fhow-should-one-handle-nsurlauthenticationmethodxmobilemeauthtoken%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What's the protectionSpace associated with these calls look like?
– Dad
Nov 20 '18 at 4:47
Have you tried calling the completion handler with NSURLSessionAuthChallengePerformDefaultHandling and nil for credential?
– Dad
Nov 20 '18 at 4:48
How about with NSURLSessionAuthChallengeRejectProtectionSpace and nil for the credential? If so, does your delegate should get called again with the next authentication projection space?
– Dad
Nov 20 '18 at 4:48