LCP: remove un-needed status requests

[llemeurfr]

When one imports a license, opens the ebook and is asked for a passphrase, there a 3 status requests.

“Etes-vous sûr de vouloir importer ces fichiers EPUB : ….” “Oui” -> status + register Open -> status puis présentation modale mot de passe “Cette publication a besoin d’un mot de passe” bon mot de passe -> status et ouverture

Would it be possible to:

• register at the moment the passphrase is recognized as ok, so that people who don't have the passphrase do not see their device registered?
• remove at least one of the status requests?

[danielweck]

Thorium checks the LSD status at key points in the UX flow, for example before displaying the "publication info" modal dialog box (so that the rendered information is correct: LCP start/end dates, as well as return/renew links), or immediately before attempting to open a LCP-protected publication (so that this can be prevented in case the LCP license has been revoked, etc.), or when initially importing a LCP license or LCP-protected EPUB, or after LSD return / return.

Furthermore, when a LCP license has been updated following a LSD check, another LSD check takes place based on the LSD link advertised in the newly-updated LCP license. In principle, this ensures that LSD changes are captured following LCP updates ... but in practice I think this is a waste of HTTP request, as the edge-cases are non-existant in the current LCP/LSD server implementations, as far as I know.

[danielweck]

register at the moment the passphrase is recognized as ok, so that people who don't have the passphrase do not see their device registered?

This is an interesting suggestion. I will look into it.

[danielweck]

Related issue: https://github.com/readium/readium-desktop/issues/996

[llemeurfr]

Let's take a new license, with a new passphrase (unknown from the reading app). 1/ I import the license -> 1.a/ status request. This one is useful, as we could have an expired license. Better to know asap.
1.b/ register. This is too early. I'd like register to come after the passphrase has been accepted. 2/ I open the book -> status request. Please suppress this one. 3/ I enter the (good) passphrase -> status request. To be replaced by a register. The response to the register is a status, therefore not need for another status request at this step.

[danielweck]

I open the book -> status request.

Shouldn't the LSD request occur every time a user attempts to open a LCP-protected publication to read it?

...I would prefer to review the existing implementation based on a comprehensive state chart. I am worried that the above example is just one specific branch in the graph, not representative of all possible flows.

[danielweck]

PS: in the state chart, each isolated node is only aware of its input(s) in order to produce output(s). There is no notion of execution context, such as whether this is a first attempt to unlock a license with a passphrase, or a subsequent attempt with a stored passphrase hash. Other examples of possible context: standalone LCP license vs. full protected EPUB, authenticated OPDS with hashed passphrase vs. user passphrase input, etc.

[llemeurfr]

ok let's design a state chart and check. I wrote this doc a long time ago, which represents the equivalent of a state diagram as text.

[llemeurfr]

I think you're right about

Shouldn't the LSD request occur every time a user attempts to open a LCP-protected publication to read it?

From my text this status request should stay.

[danielweck]

Mermaid to the rescue:

https://mermaid.live/edit#pako:eNqNVMtu2zAQ_BWCFyuAg96NIkXjV_x2mgJFU_dAk6uIKCWq5NKBYfvfS1GWTBU9VCdiOTszO1zoRLkWQAf0zbAyI19Hu4L47_OPTQkFwQzIcrglSnIoLPwk9_cP5PE0s-HmWiXvoNR9qk0O4tOl7n8MyGEyAeRZAFtk6CwRmrscCryrccMKd_4O9kxGDe1fyI978-GBHZhUbK-AsEL8S3B0IxpXRBKJgd9OGhAENUkrHzUTSQ3YrDHf9I-D4ZpgEtnugK-mJwE7bfx2IP_ndhqpPSVfoFSMQyDTSnSo9sdIQxeNhadAMDvJ7kv0DDBx7IVObUiPcZQH6DWys0h2nkwBQ3PJrC0zw3y_P2kuGfrQ3iVmMfdVeB4oFs3sUS_XxgDHRmsRaS0beGv0wJRs01hG0NXpG6uxAg4eXOepwlz-Rd-kRTC3IFdR6zppd7Z0e6_EUOrC-45W8rzWZ_KarDXKtE7WWTD-wDAeNqj6bF3hbPuOFnXZr3MRgP6F7V28exXzvLNMVWXWefCoMrtVXjuJVZVFJ5gIs7pVNn5v6jiiuNppNwG4bdOsozMhkjCddZyDtalTTZbbKMvn5AW1gYi5w3Ad_Dl0rDvtlbU17dMcTM6k8H-WU3W_o54qhx0d-KNg5teO7oqLxzGH-uVYcDpA46BPXSn8_o0k8z-knA5SpmxbHQvpXV2Llz-Ah4al

[llemeurfr]

Na na na ...

[llemeurfr]

plus d'excuse :-)

[llemeurfr]

pour mémoire :

graph TD
    A[Open the LCP license] --> B{Is the license well-formed?}
    B --> C(Fetch the status document)
    C -->|Yes| D{Is the status document<br/>available and well-formed?}
    D -->|Yes| E{Is it required to fetch<br/>a fresh license?}
    E --> |Yes| F(Fetch the fresh license)
    F --> G{Is the fresh license<br/>available and well-formed?}
    G --> |Yes| H(Replace the old license<br/>by the fresh one)
    H --> I{is the license 'ready'<br/>or 'active'?}
    I --> |Yes| J(Get the passphrase associated with the license)
    J --> K{Is the passphrase correct?}
    K --> |Yes| L{Is the  license valid?}
    L --> |Yes| M{Was the device<br/>already registered?}
    M --> |Yes| N(Open the publication)

    B -->|No| Z(Notify the user that the license<br/>is unusable and stop, with details)
    D -->|No| J
    E --> |No| I
    G --> |No| I
    I --> |No| Z
    K --> |No| K
    L --> |No| Z
    M --> |No| O(Register the device)

    O --> P{Was the registration<br/>successful?}
    P --> |Yes| Q(Store the device registration)
    Q --> N
    P --> |No| N

[danielweck]

Fixed in Thorium 3