Btw how does the js front-end currently do this check? Or does it always ask for a password for these special operations?
A header, ok :) Not part of the ocs response json. I suppose https://lukasreschke.github.io/OpenCloudMeshSpecification/#ocs-responses is already full, we cannot invent another slot here. So ok to use a header. This also allows to implement this check as a middleware in Guzzle client, without parsing the json.
Of course another option when implementing a client would be to clear the session cookies every 30 minutes.
Another option would be to detect if the request already contains basic auth credentials, and if so, to use these to refresh the 'last-password-confirm'
in the session.
See also #7753, #6476, #17434
I am using the Nextcloud API to create users, groups and similar from an external software (a Drupal website).
I noticed that cookie auth is the fastest, token auth is a bit slower, basic auth is a lot slower.
With both cookie auth and token auth, I get responses "Password confirmation is required" on routes annotated with @PasswordConfirmationRequired
every 30 minutes.
The response json is like this:
{"ocs":{"meta":{"status":"failure","statuscode":403,"message":"Password confirmation is required","totalitems":"","itemsperpage":""},"data":[]}}
In my code I am checking for $data['ocs']['meta']['statuscode'] === 403 && $data['ocs']['meta']['message'] === "Password confirmation is required"
. If the check is positive, I clear the cookies and send another request.
(I am using cookie auth, but the same would happen with token auth)
My check relies on a user interface string, which might change in future versions of Nextcloud.
Send another special string with the response, that is more reliable to detect. BUT Don't remove any of the existing parts of the response, so not to break other clients. OR Make a commitment that the string "Password confirmation is required" is not going to change, ever.
Be sure to not store and send cookies! We parse cookies first. So if you send cookies the timeout might happen after 30 minutes.
As in my comment in the other issue:
@PasswordConfirmationRequired
, e.g. /ocs/v1.php/cloud/users/{userId}/enable
.So cookie auth is still the best bet.
All you have to do is stop storing/providing cookies in your HTTP requests.
This is a bad solution, because requests without cookies are A LOT slower. For me, I measure times like this for an api request to get the admin user data:
The token auth is slower than cookie auth because it initializes the user and sets up the mount points via post_login hook. Cookie auth skips all of that. Basic auth has to validate the password, which must take time, otherwise it would not be safe.
Btw the token auth does not prevent from the "Password confirmation is required" on some routes. So it does not really solve anything.
While I run docker-compose up
in a project while the docker service is not running, I see exception backtraces like this:
Traceback (most recent call last):
File "urllib3/connectionpool.py", line 677, in urlopen
File "urllib3/connectionpool.py", line 392, in _make_request
File "http/client.py", line 1277, in request
File "http/client.py", line 1323, in _send_request
[...]
docker.errors.DockerException: Error while fetching server API version: ('Connection aborted.', FileNotFoundError(2, 'No such file or directory'))
[80446] Failed to execute script docker-compose
Would it be possible to simply detect if docker service is running, and if not, show a more meaningful message?
Docker service is not running.
Perhaps there are other scenarios where docker is not a service. So perhaps the message can be more generic.
Unable to connect to Docker.
If you use a global Docker service, you can try `service docker status` to see if the service is running, and `service docker start` to start if.
I am not sure what is the goal here, I could see two:
resource:
mechanism so it also works for factories.I am most interested in the first point.
For that, it would be most natural to have the attribute on a static method, and use the return type as the service id (unless a custom id is provided).
When doing this, I would name the attribute class Service
, not Factory
, because the fact it is a factory is already obvious.
A class can contain more than one factory, each returning a different service.
class C {
#[Service]
static function createA(): A {..}
#[Service]
static function createB(): B {..}
}
To avoid duplicates, the attribute can have a custom id, or a suffix that will be appended to the class name.
class C {
#[Service]
static function createA(): A {..}
#[Service(id: 'a.other')]
static function createOtherA(): A {..}
#[Service]
static function createB(): B {..}
#[Service(suffix: '.other')]
static function createOtherB(): B {..}
}
The #[Service]
attribute could also be added on class level to explicitly register a class as a service.
I think right now this is not needed because resource:
already registers all the classes. But perhaps there could be a different mode where this does not happen, and where only classes with #[Service]
attribute are registered as services.
OEC-893: Patch 'drupal/cas_mock_server': Allow CAS redirect to distinct domain.
OEC-893: Avoid error if user was already deleted.
OEC-893: Generate README in group folders.
OEC-893: Update README for user account creation.
OEC-893: Mention new entry in /etc/hosts in README.md.
OEC-893: Install and use cas_mock_server and EU Login mock.
OEC-893: Remove custom user_cas_eulogin fork.
OEC-893: Restructure the Docker image.
OEC-893: Use php.ini-development for Nextcloud.
OEC-893: Set distinguishable title for mock login form.
OEC-893: Rename a variable.
OEC-893: Add block to link to Nextcloud documents.
OEC-893: Enable views_ui.
OEC-893: Create view with list of groups.
OEC-893: Make groups the front page.
OEC-893: Change site name to 'Nextcloud POC Demo'.
OEC-893: Enable contextual links module.
OEC-893: Force CAS login and don't autocreate in Nextcloud.
OEC-893: Change label of e-mail address field in CAS login form.
OEC-893: Add markdown file describing the behavior.
OEC-893: Show empty block if nextcloud not configured.
OEC-893: Rename a variable.
OEC-893: Add block to link to Nextcloud documents.
OEC-893: Enable views_ui.
OEC-893: Create view with list of groups.
OEC-893: Make groups the front page.
OEC-893: Change site name to 'Nextcloud POC Demo'.
OEC-893: Enable contextual links module.
OEC-893: Force CAS login and don't autocreate in Nextcloud.
OEC-893: Change label of e-mail address field in CAS login form.
OEC-893: Add markdown file describing the behavior.
OEC-893: Encrypt cookies.
OEC-893: Add user_cas app copied from euwtamngr.
(This code violates Drupal code inspections, but that's ok.)
OEC-893: Install richdocuments app in Nextcloud.
OEC-893: Install oe_authentication.
OEC-893: Quote the ports in docker-compose.yml, to not confuse the yaml parser.
This is recommended in the compose file spec: https://docs.docker.com/compose/compose-file/compose-file-v3/#short-syntax-1
OEC-893: Drop the user_cas_eulogin fork. Use upstream app instead.
OEC-893: Fix texts in install-nextcloud.sh.
OEC-893: Remove redundant parts in install-nextcloud.sh
OEC-893: Occ install is enough, no need for occ enable.
OEC-893: Don't install user_saml.
OEC-893: Install upstream user_cas.
OEC-893: Use olivero + claro instead of bartik + seven.
OEC-893: Comments in runner.yml.dist.
OEC-893: Enable oe_authentication.
OEC-893: Change front page setting to prevent redirect loop for inactive users.
OEC-893: Use key-value syntax for docker env vars.
OEC-893: Use a custom docker image for Nextcloud.
Remove install-nextcloud.sh, it is no longer needed.
OEC-893: Install and use cas_mock_server and EU Login mock.
OEC-893: Remove custom user_cas_eulogin fork.
OEC-893: Restructure the Docker image.
Don't pass NULL to setcookie(,,*), use 0 instead.
Replace \OCP\App with \OC_App.
Replace \OCP\App with \OC_App.
I am using Nextcloud with docker-compose, with another container providing a CAS mock server.
The user_cas
app (and underlying phpCAS) has to build CAS urls for two purposes:
In a docker scenario, without additional tricks, these urls can be different. It could be useful to support distinct settings for these urls.
Btw, I considered to open this issue in https://github.com/apereo/phpCAS. But we are not even using the latest version of that, so I couldn't tell if this is not already working in latest phpCAS.
For local development I am using a mock server for CAS.
It is much easier to set this up with http
instead of https
.
However, user_cas and phpCAS assume that the CAS server always uses https.
For development purposes it would be nice to allow http-only.
And I want to point out there is a difference of http protocol for the CAS server, vs for Nextcloud.
Btw, I considered to open this issue in https://github.com/apereo/phpCAS. But we are not even using the latest version of that, so I couldn't tell if this is not already working in latest phpCAS.
Steps to reproduce:
core/modules/system/config/install/system.site.yml
.Expected: Not sure what we expect :)
Actual: EU Login redirects to frontpage, Drupal refuses to login the inactive user, Drupal redirects back to EU Login, EU Login redirects back to Drupal frontpage, etc.
Workaround: As a site builder, simply avoid having front page = /user/login.
Solution: As maintainers of this module, we simply need to push site builders to change the default front page. Perhaps having this issue here is good enough.
I would like to create a custom dockerfile with FROM nextcloud:25-apache
that installs additional apps.
This means I would need to run some occ
commands after Nextcloud has been installed.
sudo -E -u www-data php /var/www/html/occ app:install richdocuments groupfolders
The dockerfile should then be installed from docker-compose.
How could I do this?
It seems any RUN
commands in the custom dockerfile would run before the installation is complete. So at that time, occ
won't work.
I don't want to copy the entire entrypoint.sh
from the parent image, it seems wrong.
I don't know if Desktop environments provide anything beyond the icon + title to customize the taskbar items.
When having multiple Brave windows open, they all look the same in the desktop taskbar. In my case, I am using different windows with different user profiles. These windows could be made distinguishable in the taskbar by using different icons, or by prefixing the title somehow.
(In my case I am using KDE Plasma desktop environment on Ubuntu)
Use a desktop env that has a taskbar. Disable grouping of windows. Open multiple Brave windows, for multiple Brave user profiles, including incognito window.
Taskbar items all have the same icon, and are only distinguished by the title. The title is different, but it only shows the page title of the active tab in that window, which does not help to distinguish the profiles).
Different icon or a title that allows to distinguish windows for different profiles or private/tor.
always
Version 1.48.158 Chromium: 110.0.5481.77 (Official Build) (64-bit)
If it is not abandoned, I have some pull requests to make it work with latest version :) #106 #108
Deprecated: setcookie(): Passing null to parameter #3 ($expires_or_options) of type array|int is deprecated in ***.
On https://apps.nextcloud.com/apps/user_cas there is a comment saying this app is abandoned. Is this true? If not, a reply should be made.
Replace \OCP\App in templates/admin.php.