Public link password capabilities support

[jesmrec]

Currently, we deal this capability for public links:

"password": {
     "enforced": false
},

It was splitted up, and core versions from 10.0.9 will include:

"password": {
             "enforced": true, 
             "enforced_for": {
                                "read_only": true, 
                                "read_write": true, 
                                "upload_only": false
                            }
              }, 

Web UI does not allow to save the public links if the option selected has the password enforced. Other option (cooler) is setting dynamically the * to mark the field as mandatory.

To develop after 10.0.9 and #2150

Related: owncloud/core#31494

[davigonz]

This is not blocked any more, moving it to Backlog so can be prioritized and included in a milestone

[phil-davis]

Note: discussion here also about the password policy app exposing more detail in capabilities of what is required for a valid password
owncloud/password_policy#76

The capabilities here would still be the same, so not a blocker for implementing this bit! I am just posting here so people are aware that more password capability details might come...

[shashvat-kedia]

@jesmrec Is this feature still required?

[jesmrec]

yes @SD1998. Before the feature elaboration, support of the capabilities etc... we should discuss about the UI look to show (check the webUI is a good point to start)

[shashvat-kedia]

@jesmrec I am unable to check the web UI as am unable to access owncloud-server hosted from docker due to some issues in my system could you suggest an alternative way to access the UI? Thanks.

[davigonz]

I am unable to check the web UI as am unable to access owncloud-server hosted from docker due to some issues in my system could you suggest an alternative way to access the UI? Thanks.

Maybe https://demo.owncloud.org/? But I would recommend you to try to fix you docker issues as well, sometimes is tricky but worthy 😄

[jesmrec]

@SD1998 was you able to check the info? if not, i can ellaborate and paste you some screens about the feature.

[shashvat-kedia]

@jesmrec I could not find the UI corresponding to this(when talking about password capabilities we are talking about the ability to set password for different actions(read, write or upload) on a file or directory while sharing right?). A little ellaboration would be helpful. Thanks.

[jesmrec]

You can find the capabilities in the server admin dashboard, Sharing option:

Depending on the values selected there, in the capabilities request will be sent the values as i posted in the first message.

In the app:

the point is that the link for folders is not created till the password is typed in case it is enforced. The behaviour till now is that password was unique regardless the permissions.

Any question you have, please ask :)

[davigonz]

Not sure if I have misunderstood what is needed here but after checking the current Android app behaviour, it is currently doing the same as Web UI - "Web UI does not allow to save the public links if the option selected has the password enforced".

• Enforce password protection for read-only links and create a share with Download / View option => NOT ALLOWED

• Enforce password protection for read & write links links and create a share with Download / View / Upload option => NOT ALLOWED

• Enforce password protection for read & write links links and create a share with Download / View option => ALLOWED

Maybe I'm missing something? @jesmrec @michaelstingl

The behaviour till now is that password was unique regardless the permissions.

How do you set different passwords in the web UI depending on the permission selected? Can not find it.

Other option (cooler) is setting dynamically the * to mark the field as mandatory.

Yes, this could be included additionally but still think that the main behaviour requested in this issue is already implemented.

[michaelstingl]

How do you set different passwords in the web UI depending on the permission selected? Can not find it.

https://marketplace.owncloud.com/apps/password_policy needed?

[michaelstingl]

@pmaier1 Could you explain the ownCloud server behaviour and what's missing in the iOS app?

[jesmrec]

The only solution for this problem is displaying/showing dinamically the * near to Password depending the selected option.

I mean, if you enable one of the three capabilities to handle the password protection (f.ex., for Read-only), the label Password will have always the *, even though you select Only Upload where the password is not enforced.

[davigonz]

The only solution for this problem is displaying/showing dinamically the * near to Password depending the selected option.

I mean, if you enable one of the three capabilities to handle the password protection (f.ex., for Read-only), the label Password will have always the *, even though you select Only Upload where the password is not enforced.

So the support is already implemented and just the * improvement is pending. If so, I would rewrite the issue name and description since now it sounds like something bigger and more complicated

[jesmrec]

In order to set the * is needed to fetch the capability enforced_for , persist it in the database, and depending on the selected field, display it or not... so finally you are adding support beyond the UI. Tell me if i am wrong @davigonz.

[jesmrec]

Other approach is removing the * and when the password is enforced and not typed, a message error is shown. Core works in this way. Personally i do not like the core approach so it is very generical... splitting the capability allows us to show more accurate messages.

[davigonz]

In order to set the * is needed to fetch the capability enforced_for , persist it in the database, and depending on the selected field, display it or not... so finally you are adding support beyond the UI.

Yes, you're right, if we want to show the * in advance we have to persist the capability somewhere.

Other approach is removing the * and when the password is enforced and not typed, a message error is shown. Core works in this way.

Do you mean like the scenarios I included in #2228 (comment)? If so, that's why I thought the support was already included, because without the *, the app is doing exactly the same as web UI.

Personally i do not like the core approach so it is very generical... splitting the capability allows us to show more accurate messages.

They use the messages that come from the server, same as we do and are too generical, yes.

To sum up, I still do not understand for which purpose are the clients (web for example) using the enforced_for capability. I mean, there's no UI improvement in web client that takes advantage of it, it just tries to create the share and show an error if any, so what is required? Because * is just an additional UI improvement.

[jesmrec]

The purpose is that each kind of permission has its own password enforcement. Web does not take advantage, but it does not use the capability as the mobile clients does either (they do not get the JSON file). For example, web client never showed "*" in case of enforcement. Mobile clients did from scratch.

The only aim of this issue is the one explained here: #2228 (comment), assuming that the web does not behaves in such way.

[jesmrec]

Done and merged