Fix warranty check due to new GSX

[rickychilcott]

URL https://selfsolve.apple.com/wcResults.do?sn=#{serial_number}&Continue=Continue&num=0 provides adequate output that we can scrape.

[bruienne]

Just tested this edit in app/models/warranty.rb and it correctly reports warranty information again now. Thanks!

[jnraine]

@bruienne, got a commit for this one?? ;)

[bruienne]

I'd like to commit a fix, but it looks like it needs a little more work. Changing the URL makes the check at least run successfully but the data returned is not parsed correctly and the results as displayed seemed mostly be coming from the "else" clauses. I'm trudging through the warranty.rb code right now to wrap my head around it but I think it'll require changing most of the strings to match on. Also trying to figure out if the HTML pulled in from the new URL hits the 10 KB limit that makes URI.open save the content to a temp file vs. storing it in a string -- this causes the item.string method to be invalid in my testing.

[Ginja]

I have commit that should fix this warranty issue. I had to get rid of some fields though as there wasn't any data to scrape. This is what it looks like:

If that sits well with everyone, I would like for someone else to test the changes before I submit a pull request. Any volunteers?

[rickychilcott]

That's great Riley. Send it along.

Sent from my iPad

On Jun 7, 2013, at 4:03 AM, Riley Shott [email protected] wrote:

I have commit that should fix this warranty issue. I had to get rid of some fields though as there wasn't any data to scrape. This is what it looks like:

Let me know if you'd like me to submit a pull request.

—
Reply to this email directly or view it on GitHub.

[Ginja]

Wouldn't you know it? Apple has gone and changed their warranty page again. The following URL no longer works for me:

https://selfsolve.apple.com/wcResults.do?sn=#{serial_number}&Continue=Continue&num=0

They now appear to separate checking by product line (notebooks, desktops, etc...), and everything appears to be session based. If you try to enter a desktop during a notebook session it warns you (see EDIT).

During a session though, this seems to be the new URL:

https://expresslane.apple.com/Coverage.action?serialId=#{serial_number}

Good news is that it looks like it will be easier to scrape because it returns JSON values. Bad news is that the poorly written code I wrote needs to be re-written but c'est la vie.

Here is what's available:

strPhCoverage
"PP"
strMaxEligibility
"Y"
objEntitlement
"{"strC2C":"Y","strSCB":...rEML":"Y","strCLD":"N"}"
strHwCoverage
"PP"
strPhDaysLeft
"1004"
bIsError
false
strAppEligible
"N"
strRespCd
"00"
strEntSlNo
"serial_number"
strCovInfoBody
"Coverage is estimated. ..._blank">contact us."
strPhCovStatus
"Active"
strHwCovStatus
"Active"
objAgrDtlsDTO
"{"strApp":"N","strAppPr...purchased Mac OS X."}]}"

EDIT: It looks like all you need to do is visit the URL below once, and then you'll be able to successfully check a machine's warranty status with the new URL above.

https://expresslane.apple.com/GetproductgroupList.action

[rickychilcott]

Where are you seeing that? When I goto http://www.apple.com/support/, "Check your service & support coverage" still goes to https://selfsolve.apple.com/agreementWarrantyDynamic.do

Ideally, we'd be doing this through the GSX API, but that would require every munkiserver install to have a GSX account. Until we're ok with that being a requirement, web scraping will have to do.

Ricky Chilcott
[email protected]

On Jun 9, 2013, at 5:19 AM, Riley Shott [email protected] wrote:

Wouldn't you know it? Apple has gone and changed their warranty page again. The following URL no longer works for me:

https://selfsolve.apple.com/wcResults.do?sn=#{serial_number}&Continue=Continue&num=0

This seems to be the new URL:

https://expresslane.apple.com/Coverage.action?serialId=#{serial_number}

Good news is that it looks like it will be easier to scrape because it returns JSON values. Bad news is that the poorly written code I wrote needs to be re-written but c'est la vie.

Here is what's available:

strPhCoverage
"PP"
strMaxEligibility
"Y"
objEntitlement
"{"strC2C":"Y","strSCB":...rEML":"Y","strCLD":"N"}"
strHwCoverage
"PP"
strPhDaysLeft
"1004"
bIsError
false
strAppEligible
"N"
strRespCd
"00"
strEntSlNo
"serial_number"
strCovInfoBody
"Coverage is estimated. ..._blank">contact us."
strPhCovStatus
"Active"
strHwCovStatus
"Active"
objAgrDtlsDTO
"{"strApp":"N","strAppPr...purchased Mac OS X."}]}"

—
Reply to this email directly or view it on GitHub.

[Ginja]

Very interesting... I'm not sure what I was seeing before but it's back to working as per normal again. Maybe I tested at the wrong time when they were doing maintenance? Who knows, but I think I may have found a better way to scrape. Currently investigating.

[Ginja]

Alright so it looks like the new method won't be any better. While it's easier to parse the data, it doesn't give you as much information. But because Ruby is fun, I've whipped a quick script to demonstrate how it's done:

https://github.com/Ginja/Admin_Scripts/blob/master/warranty.rb

What I don't understand is the strPhDaysLeft value. I would have thought that it indicated the expiry date of a machine's AppleCare (ex: today's date + value) but in my testing that doesn't appear to be the case. Anyways the current code is working, I must have tried during some outage.

[rickychilcott]

Hi @Ginja, I wonder if it's that you get 90 days of free phone support and if you have AppleCare, then it's 90 days + 3 years. Possible?

[Ginja]

Good thinking, @rickychilcott. I didn't even think about that. However with that in mind, the dates still don't add up to the expiry date of my phone support coverage. From the screenshot above you can see my coverage expires on April 3, 2015, yet the strPhDaysLeft number would put my end date in March of 2016. And I only have about 663 days left.

EDIT: It also doesn't appear to update regularly as I've been querying it for a couple of days now and it still reports 1004.

[rickychilcott]

Ok. The numbers were roughly correct for my machine. So… it made sense. I wish we could pull more data from that script of yours. It's really clean!

Ricky Chilcott
[email protected]

On Jun 10, 2013, at 7:31 PM, Riley Shott [email protected] wrote:

Good thinking, @rickychilcott. I didn't even think about that. However with that in mind, the dates still don't add up to the expiry date of my phone support coverage. From the screenshot above you can see my coverage expires on April 3, 2015, yet the strPhDaysLeft number would put my end date in March of 2016. And I only have about 663 days left.

—
Reply to this email directly or view it on GitHub.