@phil-davis @pmaier1 IMO this works "as designed"

We can always challenge the way it is "designed"

Technically, a re-share is just a new share from the owner to the Sharee on behalf of the share initiatior.

It should not be possible to circumvent the "enforced" expiration date.

It should not be possible to circumvent the "enforced" expiration date.

That is working correctly. If I receive a share expiring in 4 days time, and the enforced maximum is 7 days, then I can make a reshare for up to 7 days and not more.

I added some test scenarios in PR #37016 to demonstrate the current behaviour. That "documents" the way it works now (which is that it allows the resharer to extend the expiration date if they wish, up to any enforced maximum). Somehow I had not already made test cases that demonstrated that.

Great spot, thx 👍

IMO when I receive a share that has an expiration date set, and has reshare permission, then I should have to keep and expiration date when I reshare it, and the expiration date of the reshare should be <= the expiration date of the received share. (i.e. I should not be able to grant longer access than the access that I received)

I agree with this. Think we should handle the expiration date just as we handle permissions in resharing, e.g., you can't exceed what you have been given in the first place. If we do not take care of this, it can cause cases where users accidentally have access to resources the owner is not naturally aware of which I find critical.

  Scenario Outline: reshare extends the received expiry date up to the default by default
    Given using OCS API version "<ocs_api_version>"
    And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "<default-expire-date>"
    And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "<enforce-expire-date>"
    And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30"
    And user "user2" has been created with default attributes and without skeleton files
    And user "user0" has created a share with settings
      | path        | textfile0.txt |
      | shareType   | user          |
      | permissions | all           |
      | shareWith   | user1         |
      | expireDate  | +20 days      |
    When user "user1" creates a share using the sharing API with settings
      | path        | textfile0.txt |
      | shareType   | user          |
      | permissions | change        |
      | shareWith   | user2         |
    Then the HTTP status code should be "200"
    And the OCS status code should be "<ocs_status_code>"
    And the information of the last share of user "user0" should include
      | expiration | +20 days |
    And the response when user "user2" gets the info of the last share should include
      | expiration | <actual-expire-date> |
    Examples:
      | ocs_api_version | default-expire-date | enforce-expire-date | actual-expire-date | ocs_status_code |
      | 1               | yes                 | yes                 | +30 days           | 100             |
      | 2               | yes                 | yes                 | +30 days           | 200             |
      | 1               | yes                 | no                  |                    | 100             |
      | 2               | yes                 | no                  |                    | 200             |
      | 1               | no                  | no                  |                    | 100             |
      | 2               | no                  | no                  |                    | 200             |

The above passes. But the middle 2 rows are a little unexpected. The received share has +20 days expiration. The default expire date is set to +30 days (and not enforced). When the share receiver reshares without specifying an expiration, then they get no expiration date (the reshare never expires).

Note: that is "consistent" with the current behaviour when creating a new share. If the user does not specify an expiration date in the API call to create the share, then they get no expiration data (they do not get the default expiration days). The default expiration days are there to be either enforced (and then you get them applied for sure) or for clients to query what is the "suggested" default, and to then do that calculation and display for users as the default. The webUI does that, and so it ends up explicitly setting what "happens to be" the default expiration days.

Thanks @phil-davis. As said above, in a reshare scenario we should stay consistent with how we treat permissions:

• The resharer can't exceed the permissions originally given
• The resharer can't exceed the expiration date originally given, e.g., if it's February 26th and a received share will expire on March 4th, then resharing this will have an enforced maximum expiration date of March 4th no matter if the global setting enforces an expiration date or not.

If we don't do this, resharing will provide a way to bypass the expiration date. Even if the maximum expiration date is enforced you could keep a share indefinitely by resharing back and forth with third parties.

Just thinking out loud: Another option would be to disallow resharing if a share has an expiration date. Not sure if gusta :)

IMO @pmaier1 requirement spec above ^ is "a good thing".

Note: currently (when the default expiration days is enforced as maximum) the original sharer can come back every few days and extend the expiration date of the share out to the "new maximum". (that is OK - it is equivalent to anyway deleting the share then creating it again with new (later) expiration date)

When coding the resharing limits, the code will need to find the current expiration date of the received share, to enforce that as the maximum for a new or edited reshare.

It will be tricky if the original sharer edits the share and reduces the expiration date, when the share has already been reshared... Does the code then loop through all reshares "down the tree" and reduce the expiry date of those? or? (IMO probably leave them - the original sharer can see all the reshares in the UI anyway at the time they reduce the expiration date, so they can/should review those...

Also if Anne shares with Bob with some expiration date, and Bob reshares to a group (and group sharing has some different expiration date expiration default/enforced...) then the code will have to be careful that it respects the expiration date of the received user share, and the group sharing expiration parameters.

And similar if Bob reshares as a public link - the public link should get some expiration...

Priority? Is this a blocker for 10.4.0? Or can the logic for reshare expiration date limits be sorted out for 10.4.1?

@phil-davis We will doo a quick hands-on trial now and then decide.

Decision has been made: Not a blocker for 10.4.0

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

This issue has been automatically closed.

There are test scenarios tagged @issue-37013
For example, see https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiShareReshareToShares3/reShareWithExpiryDateOc10Issue37013.feature

This is still "a thing".

@JammingBen this is something that should be sorted out some day. I wonder if it is easy to control the expiration date when resharing? We do it with permissions (the reshare cannot exceed the permissions of the received share), so maybe in a similar place we can check that the requested expiration date of a reshare is at or before the expiration date of the received share.