Prevent authentication attempts from bubbling upwards

Zope
#1

Hi,

I have a ZODB structure like the following:

root/
├── acl_users
└── main_app
    ├── api
    │   ├── acl_users
    │   └── crm
    └── user folder(PluggableAuthService)

The acl_users folder within the api folder is used for the external service to connect to the api.

This works when the correct credentials are provided, but in case there is e.g. a problem with the password, there is an automatic attempt to authenticate at the user folder from above (PluggableAuthService), which
a) can never succeed anyway
b) sends the api-client an HTML page with a login dialog via a 302

Is it possible to prevent that the failed login attempt bubbles up and tries to authenticate with the user folder provided by PluggableAuthService?

Thanks!

#2

No (at least not easily): bubbling up of authentication trials is implemented by BaseRequest.traverse - this means at quite a low level.

But you can nevertheless achieve that a higher up user folder cannot override a negative decision of the lower user folder. To achieve this, you lock the response status in the challenge plugin (your lower level user folder likely sets to status to 302 (redirect) to get your own login form). The higher level user folder will still get control but its challenge can not override the locked status.

1 Like
#3

Thank you for the quick response.

I have no concerns, that a higher level folder will undo the negative decision, as the username only exists in the user folder for the api.

I am not sure what you mean with "lock the response status" or how to do it.

The user folder for the api is a simple "User Folder" (from OFS) which came along a standard Zope installation. At least in the ZMI I see no configuration options, except these here...

Screenshot from 2021-02-16 12-35-53

At the higher level user folder (PluggableAuthService) I have the following configuration:

Screenshot from 2021-02-16 12-42-27
Screenshot from 2021-02-16 12-42-27771×580 33.9 KB

I am wondering why an XML-RPC-call to my api, can bubble up here and finally trigger the cookie_auth and its HTML login form. I am not super familiar with PluggableAuthService, but from the configuration I would assume only the basic_auth plugin is triggered, not the cookie_auth one. At least that is what I deduct from the 302 the XML-RPC client gets as a response.

I will probably start a debugger and have a closer look what is going on in detail.

#4

Look at ZPublisher.HTTPResponse.HTTPResponse for parameters named "lock". They are used to "lock" various parts of the response where "lock" means "cannot be overridden" (via the official API).

#5

I would use roles and permissions do disallow user actions and not login.

1 Like
#6

I would use roles and permissions do disallow user actions and not login.

Right. This would mean a lot of upfront work, as - when the system was planned 17 years ago, everybody was allowed to do everything... long story.

#7

@dieter Thanks, but I have no clue how I would be able to set lock there, as the request does not pass to my code, but gets handled by both the user folders.

Maybe I find time to dig a bit deeper.

#8

Ok, this a valid reason to look for a different approach.

Plone Foundation Code of Conduct