Permanent Still URLs when asset is not protected

[Frans]

When there is no access restriction on the asset, the URLs to the Still images should be permanent and should not contain any ticket info

[forgacs]

Please, confirm it:

Static (permanent) still links development:

For creating static still links we will be re-using the ticket still URL;
/still/$mediafile_id

The static link will only be used when there are no ACL rules on objects;

- The asset of the still / mediafile.
- The still

If there is no ACL rule on these both objects, then a static link will be used.

In case of an ACL rule on one of these objects will re-use the ticket system and
use a new URL;
/still/ticket/$ticket_id

This static/ticket URL is returned during REST calls where we provide the still
URL, f.e. the /asset REST call.

The static link is generated only once and is removed when any ACL is put on
either the asset or the still itself.

[Frans]

Agree with the proposed solution. Will consider same functionality with mediafiles too, but then I'll submit a new ticket for that.

[forgacs]

@Robert: Please, review the solution.

[Michiel.Schok]

I've looked through the various scenario's. Mostly good results, but room for improvement. Let Frans decide what to do.

OK: When there is no ACL involved (on asset, mediafile or still), I get a static ticketlink, that does not change between calls of /asset/{id} or /asset search calls. Great.

Improvement: When the browser requests the image, a cache line is given that expires immediately. Subsequent page visits fetch the image again.

Last Modified	Tue Nov 23 2010 10:12:48 GMT+0100
Last Fetched	Tue Nov 23 2010 10:12:48 GMT+0100
Expires	Thu Jan 01 1970 01:00:00 GMT+0100

OK: When an ACL is put on the asset (/asset/{id}/acl?aut_domain=foo.nl), the still tickets are uniquely generated. Removal of the ACL returns default behaviour of the permanent URL.

Possible improvement: When an ACL is put on the asset, the permanent still returns a 404-status code, with text 'mediamosa exception 403 was thrown'.

Not good: When an ACL is put on the original mediafile (/mediafile/{id}/acl?aut_domain=foo.nl), the still tickets are still permanent as if no ACL is defined.

OK: When an ACL is put on the still-mediafile, the still tickets are uniquely generated.

Improvement: the ACL on the 'still-mediafile' does not work. Regardless of the ACL, always a ticket is given.

Possible improvement: in the /asset/{id} response, two ticket-links to the still are given.

  <items>
    <item id="1">
      <asset_id>lbUHVTgGjpMUovDhfTqlxfNd</asset_id>
        ...
        <vpx_still_url>http://app.acceptatie.vpcore.snkn.nl/still/ticket/N1YlsFaVWyHei6RvNOfcrVzu</vpx_still_url>
...
      <mediafiles>
        <mediafile id="1">
          <mediafile_id>OkIfMthgbbEcOdglrKVI5Y4M</mediafile_id>
...
          <still>
            <mediafile_id>B1sHs8FVUEnMIf8OHdC9HpwK</mediafile_id>
...
            <still_ticket>http://app.acceptatie.vpcore.snkn.nl/still/ticket/w2IoZRGH8VRKSDJUEcYPHz4u</still_ticket>
...

Maybe they could point to the same ticket, so we don't need get ticketlinks for one call?

[MC-arjen]

Replying to Michiel.Schok:

I've looked through the various scenario's. Mostly good results, but room for improvement. Let Frans decide what to do.

OK: When there is no ACL involved (on asset, mediafile or still), I get a static ticketlink, that does not change between calls of /asset/{id} or /asset search calls. Great.

Improvement: When the browser requests the image, a cache line is given that expires immediately. Subsequent page visits fetch the image again.
{{{
Last Modified Tue Nov 23 2010 10:12:48 GMT+0100
Last Fetched Tue Nov 23 2010 10:12:48 GMT+0100
Expires Thu Jan 01 1970 01:00:00 GMT+0100
}}}

Well, this would make the caching of browsers/webservers useless. Is there a specific reason for this wish? How about only changing the modified stamp if something changes to an asset/mediafile?

OK: When an ACL is put on the asset (/asset/{id}/acl?aut_domain=foo.nl), the still tickets are uniquely generated. Removal of the ACL returns default behaviour of the permanent URL.

Possible improvement: When an ACL is put on the asset, the permanent still returns a 404-status code, with text 'mediamosa exception 403 was thrown'.

That was strange, true. It is a 'real' 403 (forbidden) now.

Not good: When an ACL is put on the original mediafile (/mediafile/{id}/acl?aut_domain=foo.nl), the still tickets are still permanent as if no ACL is defined.

After some discussion about this; this would make the construction hard to understand and to implement. This is also not the way access to other mediafiles in the asset work. We have a use case of 1 asset with 2 mediafiles, where 1 is protected (for example hd quality) and 1 is not (preview version). We always look at the acl rules of the requested mediafile regardless of how the original mediafile is protected.

The idea is that stills are mediafiles, and have their own acl rules. So stills are permanent if it has no own acl rules and the asset does not have acl-rules on itself, just like any other mediafile.

In relation to this: we could discuss the "inherit_acl" option on still generation?

OK: When an ACL is put on the still-mediafile, the still tickets are uniquely generated.

Improvement: the ACL on the 'still-mediafile' does not work. Regardless of the ACL, always a ticket is given.

done in 2.3.3 (see above for the relevance of this).

Possible improvement: in the /asset/{id} response, two ticket-links to the still are given.
{{{
<items>
<item id="1">
<asset_id>lbUHVTgGjpMUovDhfTqlxfNd</asset_id>
...
<vpx_still_url> http://app.acceptatie.vpcore.snkn.nl/still/ticket/N1YlsFaVWyHei6RvNOfcrVzu</vpx_still_url>
...
<mediafiles>
<mediafile id="1">
<mediafile_id>OkIfMthgbbEcOdglrKVI5Y4M</mediafile_id>
...
<still>
<mediafile_id>B1sHs8FVUEnMIf8OHdC9HpwK</mediafile_id>
...
<still_ticket> http://app.acceptatie.vpcore.snkn.nl/still/ticket/w2IoZRGH8VRKSDJUEcYPHz4u</still_ticket>
...
}}}
Maybe they could point to the same ticket, so we don't need get ticketlinks for one call?

Ok, in the case of permanent links this makes good sense.

[Michiel.Schok]

In reply to Arjen:

Improvement: When the browser requests the image, a cache line is given that expires immediately. Subsequent page visits fetch the image again.

    Last Modified Tue Nov 23 2010 10:12:48 GMT+0100
    Last Fetched Tue Nov 23 2010 10:12:48 GMT+0100
    Expires Thu Jan 01 1970 01:00:00 GMT+0100

Well, this would make the caching of browsers/webservers useless. Is there a specific reason for this wish? How about only changing the modified stamp if something changes to an asset/mediafile?

In my comment, I was not describing the improvement, it was a description of the actual situation. At the moment, the cache lines that VP-core is providing to my browser tell it to
1. revalidate the image (that's good, it could be removed)
2. don't cache it (not good)
3. in case #2 is not working or missing, expire the image on or after jan 1st 1970.

Effective result at the moment is that my browser does NOT cache the images and reloads them every time from the site.

Not good: When an ACL is put on the original mediafile (/mediafile/{id}/acl?aut_domain=foo.nl), the still tickets are still permanent as if no ACL is defined.

After some discussion about this; this would make the construction hard to understand and to implement.

OK, that makes sense. Unfortunately SURFmedia in its current implementation is not aware of mediafiles that don't appear in the /asset/{}/mediafile call on top-level . And in it's current implementation the still is at a lower-level, added to the original mediafile.

[robert]

My proposal;

A global setting (All apps) and override setting on the client application on which the expire date will be set / used on the stills

The options;
- Always expire (like now)
- Expire in 1 month (default)
- Expire in # years, # months, # days.

[Michiel.Schok]

Good suggestion.

Spoke with Arjen this morning: this issue is not a blocker for 2.3, the current behavior in 2.3 (always expire) results in same experience for our users as behavior in 2.2 (no caching possible).

Can be in a subsequent 2.3 release, or next 3.0 version.

[robert]

See ticket #472 as follow-up.