The following reply should have been sent via email -- but unfortunately, the functionality stopped again working (this time due to "spam" prevention).
From: "Dieter Maurer" dieter@handshake.de
To: Plone Community community+0e85e820f26781bdd0374178291fa78e@plone.org
Subject: Re: [Plone Community] [Zope] Help needed on content-length issue and Un authorization issue for redirection
Date: Tue, 2 Jan 2024 08:54:16 +0100
Buvi via Plone Community wrote at 2024-1-2 06:23 +0000:
...
Issues:
- When the user is login in for the first time, ideal scenario is to give the login page to enter the username and password.
what i did is created a login page using the response.write method pushed the login page for the user
"response.write" is for special applications only.
Typically, you do not use it for a login page -- or anything you
can generate via a Page Template, DTMLMethod or DTMLDocument, Script(Python),
etc.
A "login" functionality is typically implemented via a template
representing the login form and some logic to implement the
associated login action, this logic verifies the correctness
(comparing the form provided data against a user source)
and sets up an authentication session (usually via setting a cookie).
If you follow this route, the framework handles the response headers
and body by its own -- no need for response.write.
Implementing the "login" functionality correctly is not trivial.
You may look at Products.PluggableAuthService, a Zope extension.
It allows to implement the various subtasks associated with
authentication via plugins.
It comes with plugins for a simple user source and
a login form and cookie based login functionality (--> cookie_auth_helper).
You will need something of your own to populate the user source,
e.g. implement a registration form.
framework is understanding it has Unauthorised and framework is pushing the unauthorised body(Unauthorizsed message) and appends it to the response.body.
You have not told us how you tried to implement your "login page".
The use of response.write is not responsible for an "Unauthorized"
response (even though, you should not use response.write for this
purpose). Almost surely, the "Unauthorized" is raised when you
"login page" is accessed initially (due to bad security declarations).
You can analyze "Unauthorized" problems by configuring
Zope for "verbose security". This is far less efficient (you
do not want it in production),
but gives detailed information why "Unauthorized" has been raised.
Look at the comments in the Zope configuration file (typically
etc/zope.conf) to learn how to configure Zope for verbose
security.
where response.setbody method is setting the content-length to response.body message not to the response.write value, due to which content-length is setting to lower value, than the expected value of response.write.
Usually, you do not call response.setBody either.
Typically, it is done automatically for you.
You are trying to use the Zope framework at a far too low level.
You should start with reading the Zope documentation
at "Zope documentation — Zope 5.9 documentation".
There are essentially two high level APIs:
- the old one based on management via the Web (called the
"Zope Management Interface") documented in the "The Zope Book"
- the new file system based API centered around components
(utilities, views, adapters, events) documented in the
"Zope Developer's Guide".
Both documents are linked from the main Zope documentation.
- When i use response.redirect to bring up the login page, there also i see the Unauthorised is been set to the response.body due to this unauthorised, response.status is been set 401 instead of 302(redirection status code).
As before, the "Unauthorized" is likely generated at the initial
access to whatever you have implemented (due to wrong security
declarations). If this is true, then your response.redirect
has not been executed at all.
If response.redirect is executed, it can "lock" the response code
(using the "lock" parameter with a true value).
But, as written above, you code likely is not executed at all.