app_ids:add does not seem to work

[Saturn49]

I'm getting an error when I try to use app_ids:add Name=SomeName

421 => for https://developer.apple.com/services-account/XXXXXX/account/ios/identifiers/addAppId.action?content-type=application/x-www-form-urlencoded&accept=application/json&requestId=XXXXXXXXXXX-XXXX-XXXX-XXXX-XXXXXX&userLocale=en_US&teamId=XXXXXXXXX -- unhandled response. Use --trace to view backtrace

[RocketPop]

I'm seeing this too. And the --trace is here:

/Library/Ruby/Gems/2.0.0/gems/mechanize-2.5.1/lib/mechanize/http/agent.rb:304:in fetch': 421 => for https://developer.apple.com/services-account/<removed>/account/ios/identifiers/addAppId.action?content-type=application/x-www-form-urlencoded&accept=application/json&requestId=55e247c2-7dde-xxxx-xxxx-67f8192e427b&userLocale=en_US&teamId=<removed> -- unhandled response (Mechanize::ResponseCodeError) from /Library/Ruby/Gems/2.0.0/gems/mechanize-2.5.1/lib/mechanize.rb:1229:inpost_form'
from /Library/Ruby/Gems/2.0.0/gems/mechanize-2.5.1/lib/mechanize.rb:515:in submit' from /Library/Ruby/Gems/2.0.0/gems/mechanize-2.5.1/lib/mechanize/form.rb:178:insubmit'
from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/agent.rb:326:in add_app_id' from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/commands/app_ids.rb:63:inblock (3 levels) in <top (required)>'
from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/commands/app_ids.rb:57:in each' from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/commands/app_ids.rb:57:inblock (2 levels) in <top (required)>'
from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/command.rb:180:in call' from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/command.rb:180:incall'
from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/command.rb:155:in run' from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/runner.rb:421:inrun_active_command'
from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/runner.rb:81:in run!' from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/delegates.rb:8:inrun!'
from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/import.rb:10:in `block in <top (required)>'

[robwithhair]

I am getting the same error

[toobulkeh]

So I've been messing around with this this evening, and I noticed a few things that are odd.

1. I'm not positive that the adssuv cookie should be decoded before sending as a form variable. It has a carriage return at the end, and usually some other characters in the middle, but all I have is my chrome inspector to tell me if it should be encoded or not. I tried both, neither work.
2. I think the referrer_uri is wrong, though I doubt that really matters. I think this has to do with the fact that it comes from a specific formId instead of a different action -- I'm not sure how to directly override this with mechanize to test it, so it's just a hunch.
3. The cupertino gem ignores a JSON POST that exists on the current website:
   Request URL:https://developer.apple.com/services-account/XXX/account/ios/identifiers/validateAppId.action?content-type=text/x-url-arguments&accept=application/json&requestId=XXX-XXX-XXX-XXX&userLocale=en_US&teamId=XXX though I don't think it matters. I went ahead and tested including this and a form.submit followed by form.action = "https://developer.apple.com/account/ios/identifiers/bundle/bundleConfirm.action" form.submit seems to work just as well (that is, it still just dumps to 421 client error on the NEXT form submit).

Still investigating.

[RocketPop]

Thanks for looking into this. My webdev/Ruby is too weak to help :)

[toobulkeh]

So I've finally figured out the weird patterns that this gem has and was able to tracedown and stub out the proper steps. Unfortunately I don't see what's wrong with my code, so I'm not doing a PR for it. Anyone's willing to chime in...

Note that our fork has other resources in it.

[toobulkeh]

So I've actually encountered what I think is the core problem, which is the inclusion of CSRF headers in the final JSON ajax form submission. Not all of their forms have it (creating certificates don't) but I believe adding app_ids and creating provisioning profiles both do.

I'm investigating a way to overcome this now, as it's not designed to protect against XSS (no captchas) so I should be able to overcome it.

[toobulkeh]

See sparklemotion/mechanize#408 for some more details and discussion.

[toobulkeh]

Good news, this is finally fixed. I was missing the CSRF technique that Apple implemented (not XSS, so I think we're still in the clear).

I'll submit a PR after I work out a cleaner pattern, return some proper ID codes (instead of just assuming it works) and automate the last few things that are interactive (team selection, ew.)

[toobulkeh]

Here's a link to a fix incase anyone needs it before next week (or if I spontaneously combust) - https://github.com/QueueSoftwareInc/cupertino/commit/8edb126f75217e798ae3f401e05463da607275fa

[RocketPop]

Hmmm. @toobulkeh did you spontaneously combust? :) I may try your fork if this is fixed over there

[toobulkeh]

Oops! Sorry about that @RocketPop -- I did a PR for our fork which works: #185

You might also want to check out this suite of tools, I haven't personally tried it, but it looks promising:
http://fastlane.tools/