Forum Discussion

TommyTheKid's avatar
TommyTheKid
Visitor
16 years ago

roVideoScreen - BIF URLs dont load with the screen.AddHeader

I have the workaround for HTTP BASIC auth (screen.addheader....) and its working for the video URL, but the BIF urls do not load. I imagine that they must have their own "http" object that I need to add a header too? I will probably want to know the same about artwork. I assume that will be an "addHeader" on the roSpringboardScreen object?

EDIT: I should have noted that the BIF urls DO load if I move them to a NON-HTTP AUTH required path, but that is not desirable.


Tommy
Roku Developer Program

2 Replies

  • RokuKevin's avatar
    RokuKevin
    Visitor
    16 years ago
    There is not an ifHttpAgent interface around the BIF url fetch.... However the roSpringboardScreen and other screen objects have it and can do the BASIC auth technique.

    --Kevin
  • TommyTheKid's avatar
    TommyTheKid
    Visitor
    16 years ago
    If I understand it correctly, a BIF file is basically a bunch of indexed screenshots of the movie content. If I want to protect the movie itself, I believe it stands to reason that I'd want to protect the screenshots too? Along with any artwork, and XML files. (the XML files are easy as they are roURLTransfer objects)

    I'd like to vote for an RFE to have authentication capability added to roVideoScreen, both SSL and regular (digest) AUTH. I'd also like for http object used for roVideoScreen to use the same auth/headers/credentials/ssl certificates/etc as the media URLs. I suppose I could see value in setting them separately, but at the most basic level it seems like they would be the same by default.

    How much storage does the Roku have in /tmp? Maybe files could be fetched with roURLTransfer ahead of time, and just referenced using /tmp names? I am sure that's not ideal, if it even works. Just a thought incase someone is more motivated than me to find a workaround. I can live without BIF 🙂

    Tommy