Closed alpennec closed 3 weeks ago
same issue here
Also having the same issue with the same error
me too
Looks like the sign in URL's are getting 503's now...
https://idmsa.apple.com/appleauth/auth/signin } { Status Code: 503, Headers {
Connection = (
"keep-alive"
);
"Content-Length" = (
190
);
"Content-Type" = (
"text/html"
);
Date = (
"Sat, 19 Oct 2024 02:10:35 GMT"
);
Server = (
Apple
);
} }
This is something I observed too while using another library using the same URL to sign in to an Apple account. Is it possible Apple changed something to prevent these kind of logins? Is there a new way to do that now?
same issue
macOS Sonoma 14.7 (23H124) Xcodes: 2.3.0 (28)
Welp. Same.
Same issue here
Same. Thought I was blocked by Apple 😅
Same issue
Yup same here
sudo xcodes install 12.5.1
The operation couldn’t be completed. (DecodingError.dataCorrupted(Swift.DecodingError.Context(codingPath: [], debugDescription: "The given data was not valid JSON.", underlyingError: Optional(Error Domain=NSCocoaErrorDomain Code=3840 "Unexpected character '<' around line 1, column 1." UserInfo={NSDebugDescription=Unexpected character '<' around line 1, column 1., NSJSONSerializationErrorIndex=0}))))
I have tried version 2.1 and 2.2 - the issue is same.
At this point, I don't think authentication within the app will work again until the new authentication method used by Apple is cracked. Some progress in the fastlane issue here.
Same issue
same here
Sonoma 14.1.1 Xcodes: 2.3.0
Hey everyone. Please be patient as I work through the changes to log in.
It is effecting everyone regardless of version or OS so no need for any extra comments.
Workaround is to log into developer.apple.com and download it manually. Runtimes do not require logins so those will still work.
same here
I don't kmow if this helps, but it worked on Oct 18th on a Macbook Pro running Sequoia 15.01 but not on Oct 19th on a Macbook Pro running Sonoma 14.5.
I don't kmow if this helps, but it worked on Oct 18th on a Macbook Pro running Sequoia 15.01 but not on Oct 19th on a Macbook Pro running Sonoma 14.5.
It's apparently related to a change in Apple's authentication apis.
Same issue, following for resolution
SAME ISSUE.
For reference, Fastlane just came out with a new authentication approach to address this.
Same issue, Please update when this can be resolved.
same issue - following
Yup. Same - tracking issue.
Same issue
same issue - following
I have the same issue too
+1
Same issue
Same issue.
+1
+1
+1
It looks like the fix that fastlane implemented, as mentioned by @davedelong, involved rolling @snatchev's fork of sirp (and the work he did on it) into @fastlane.
It might not be as straightforward for us because it's in Ruby, but between the work and documentation on the fork and the implementation details by fastlane, we should have enough information to create a solution in Swift.
ETA:
Hey everyone. Please be patient as I work through the changes to log in.
It is effecting everyone regardless of version or OS so no need for any extra comments.
Workaround is to log into developer.apple.com and download it manually. Runtimes do not require logins so those will still work.
@MattKiazyk is there anything that the rest of the community can do to be helpful?
I'm working on it in the evenings when family and work stuff is done. My first pass last night didn't pan out, and is highly to do with me not fully understanding crypto enough to be productive in the space. If there are dev's that are more knowledgable in the crypto world and can translate the library, I'm all for the help.
Just googling around, did you check out https://github.com/adam-fowler/swift-srp?
I have the same issue
Ok I need some help 🙏
I've tried for several nights trying to get things to work, and haven't had success. My Cryptography course 25 years ago isn't paying off.
I've pushed a branch - https://github.com/XcodesOrg/XcodesApp/tree/matt/SRPLogin
srpLogin
call that starts everything and has the outline for the calls to Apple - /init
/complete
. I think I'm close - so i'm now asking for help if anybody has more knowledge that could get this over the finish line.
Gonna take a look on this.
Update: I've found something looks promising: https://github.com/foxt/js-srp-gsa/commit/8fe53ac7c3f2c4291ebd36ff20e9ce1a2e762ee2
Update 2: I've check code above will get you signed in. The result code 409 (conflict) indicates that not all account are using SRP protocol for authenticate. I was redirect to use authentication method "authType": "hsa2"
I think there would be a better solution: Run a WKWebView to let user sign in and we grab the cookie and sessions for that purpose. I've tested it to work. Give me a little bit of time I'll write you a package.
Update 3: I've trimmed request down to following, where myacinfo exists in cookie.
curl 'https://appstoreconnect.apple.com/olympus/v1/session' \
-H 'Cookie: myacinfo=xxxxxxxxx'
Task complete. See https://github.com/Lakr233/AppleWebLogin for my code.
In my understanding, directory service id, aka prsId, is the only stuff we need to download packages from App Store. And, by using my package, user is able to sign in via touch id.
I've found this very useful. Might be better if you are looking for something more robust.
Task complete. See https://github.com/Lakr233/AppleWebLogin for my code.
In my understanding, directory service id, aka prsId, is the only stuff we need to download packages from App Store. And, by using my package, user is able to sign in via touch id.
Interesting approach - let me play with this! Thanks
It won't however work for the CLI - so the original problem still exists but if the UI doesn't need to ask for password I'm all for it.
same
Task complete. See https://github.com/Lakr233/AppleWebLogin for my code.
In my understanding, directory service id, aka prsId, is the only stuff we need to download packages from App Store. And, by using my package, user is able to sign in via touch id.
@Lakr233
So in my tests, while this allows the user to log in, and you can get a user object, the acinfo
cookie is not enough to give authorization to the download URL - ie: https://developer.apple.com/services-account/download?path=/Developer_Tools/Xcode_16.2_beta_1/Xcode_16.2_beta_1.xip
.
The request come in two path, first request is as the url provided above.
curl https://developer.apple.com/services-account/download\?path=/Developer_Tools/Xcode_16.2_beta_1/Xcode_16.2_beta_1.xip -k -v \
-H "cookie: myacinfo=xxx"
This will return a new cookie called download auth
inside the header:
< set-cookie: ADCDownloadAuth=xxxxxxxx;Version=1;Comment=;Domain=apple.com;Path=/;Max-Age=108000;Secure;HttpOnly;Expires=Thu, 24 Oct 2024 03:12:25 GMT
With this header, you make another request corresponding to 302 status:
curl 'https://download.developer.apple.com/Developer_Tools/Xcode_16.2_beta_1/Xcode_16.2_beta_1.xip' -k -v \
-H 'cookie: ADCDownloadAuth=xxxxxxx'
It will send you Xcode.
< HTTP/2 200
< accept-ranges: bytes
< content-type: application/octet-stream
< server: AmazonS3
< content-length: 2865851655
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
If you are using URLSession to access first request, it will follow the 302 redirection but your cookie is discarded iirc.
If the code above does not work anyway, I suspect the code from ipsw
cli is the solution we gonna copy.
Interesting approach - let me play with this! Thanks
This will work within your binary command line Xcodes. As long as you don’t use SwiftUI and create things like NSWindow manually, you should be fine. Additionally, recent attackers have demonstrated that they can abuse the headless WebKit, which is invisible to users, to trigger the system-wide login dialog from a command line tool.
Therefore/Additionally, I recommend copying my code into your repository to avoid any trust issues if you choose to go with my solution.
Update: I cleaned up a bunch of the code and have a simple SRP client, but something still doesn't work. If anybody else wants to look. https://github.com/XcodesOrg/XcodesApp/tree/matt/SRPLogin
I don't know Swift, but I want to call out that Apple's algo does something non-standard here: https://github.com/XcodesOrg/XcodesApp/compare/main...matt/SRPLogin#diff-e67960759f54af30fce32bb793cc6ed7a70a0b26304c10f1855e2ce87079e14bR119
Specifically, notice https://github.com/snatchev/sirp/blob/master/lib/sirp/sirp.rb#L115-L119
There are the 2 hashes of hexstrings. So something like: hash(hex(salt) + hash( hex(":" + encryptedPassword)))
.
Describe the bug I try to sign in with my email address and password.
To Reproduce Steps to reproduce the behavior: try to sign in within the app (Settings)
Expected behavior I should receive a 2FA request on an associated device
Screenshots If applicable, add screenshots to help explain your problem.
Version