Content Server with iPad problems

Bug #1013976 reported by Mythlandia
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
calibre
Won't Fix
Undecided
Unassigned

Bug Description

When I log onto the content server running on Windows 7 on my local wireless network from my iPad 3 I am asked to authenticate twice.
Then when I have downloaded a book and imported it to iBooks, I use the back browser function to return to my list of books. Unfortunately, although it continues to show the number of books found, it fails to display the actual books, so no more can be downloaded. If I search again with either the same or different terms it continues to show the correct number of books, but fails to display them.
If I close the browser tab and go back in it still fails, but if I terminate the browser and return it works again - albeit with the same issues reported above.
If I chose the mobile browser interface, that works.

I believe this all used to work many moons ago, so is this a bug or have I failed to update some security setting?

Calibre 0.8.55
User name and password three alpha chars. Get warning that password might not be valid for some devices, but cannot find a password that is considered acceptable. Still get the warning with no password.
Local Windows task has no problem, but then does not open the PDF in browser.

--------------------------------------------------------------------------------

Related branches

Revision history for this message
Kovid Goyal (kovid) wrote : Re: calibre bug 1013976

I dont have an iPad, so I cannot debug this issue. I can tell you that
none of the symptoms you describe happen on any other device. I tried it
with desktop browsers (firefox/chrome), an android phone and the kindle
Fire. Of course in these devices there is no need to click the back
button, but since you say that the problem happens even if you try the
search again, I dont see what difference that makes.

If you are using your local network, then I suggest simply not setting
a password. The problem is not the type of password, but setting a
password at all. Some devices do not support authenticated access.

 status wontfix

Changed in calibre:
status: New → Won't Fix
Revision history for this message
Kovid Goyal (kovid) wrote :

On second thoughts there is something I could do to help this situation.
I have no idea if it will actually work, since I dont have an iPad, try
the next calibre release.

  status fixreleased

Changed in calibre:
status: Won't Fix → Fix Released
Revision history for this message
Kovid Goyal (kovid) wrote : Fixed in lp:calibre

Fixed in branch lp:calibre. The fix will be in the next release. calibre is usually released every Friday.

 status fixreleased

Revision history for this message
Charles Haley (cbhaley) wrote :

Kovid, I suspect that the download is done by a different app than the browser, which causes the second auth request because the second app, perhaps the PDF reader, isn't sharing the authentication cookie. Further, the second app invalidates the original cookie. Assuming that iMumbles can support digest auth (not at all guaranteed), your fix should take care of the invalidated cookie but I think that the double auth will remain.

Revision history for this message
Kovid Goyal (kovid) wrote : Re: calibre bug 1013976

I actually dont understand why it would ever need to double auth. But
since the OP reports that it used to work, hopefully the fix will get it
back to where it was, by disabling the cookie auth for iDevices.

Off topic rant: What is it with mobile device manufacturers, are they all
incapable of implementing HTTP Auth?

Revision history for this message
Mythlandia (ahil) wrote :

Tried with no password, did not affect anything.
When downloading an ePub book, the is no problem. It is only PDFs.
Whether the PDF is downloaded from the main web pages or from the mobile interface, the result is the same: the main web pages cease to work and the mobile pages continue to work. Assuming that the mobile interface is using the original cookie, then whatever is invalidated by the PDF download can't just be invalidating that cookie or the mobile interface couldn't continue to work (could it?)
Once it is not working, the main interface with the calibre logo etc continues to display, as does the count of books found AND when the search starts, it does display the "Loading, please wait..." message, which is wiped once the book list is supposed to be rendered.
Will try your next release and report back.

Thanks for looking at this.

BTW as a presumed ebook affectionardo, I am amazed you don't have an iPad 3: the rendering is out of this world, so much better that anything else I've ever seen. Maybe Santa will be kind to you! :)

Revision history for this message
Kovid Goyal (kovid) wrote :

Reading from backlit screens gives me a headache, so no ipads for me :)

If the problem is specific to PDF downloads and turning off
authentication makes no difference, then the fix I made will also make
no difference. It seems like something in the ipad browser is causing
ajax requests to break after the pdf plugin is activated. I have no clue
what might cause that, or how to fix it. I'll need an iPad to proceed
further on his issue.

  status wontfix

Changed in calibre:
status: Fix Released → Won't Fix
Revision history for this message
Mythlandia (ahil) wrote :

I understand that it is difficult to correct without an iPad, but there is one large clue here, and I am very willing to test code sent to me.
As the Mobile version works flawlessly and the Standard does not JUST FOR THE BOOK LIST PORTION, some additional validation (or lack thereof) must be going on between the two versions. Both are just producing lists, but one produces the list "inline" and one appears to insert it later.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.