I'm looking at things like Symfony's AccessDeniedHttpException, and I definitely don't know enough to rule out that such a condition could be reported during processing. Due to underlying conditions occurring during internal processing, that are not uniquely or closely related to UCP profile field handling itself.
Have you viewed your database contents before, such as by using phpMyAdmin or similar to view the "raw" SQL data? Or even just generating one of the .sql dump files created by phpBB's own database backup function in ACP Maintenance, and viewing the contents of that backup file in Notepad++ or something else that is able to deal with the huge text file size.
phpbb_website
profile field definition that exists on the site where you're having trouble updating the field contents. e.g. Maybe something corrupt or unexpected about the validation expression or other parameters. For example, what I think a default phpbb_website field definition would look like is this:Code: Select all
# Table: phpbb_profile_fields
...
(6, 'phpbb_website', 'profilefields.type.url', 'phpbb_website', '40', '12', '255', '', '', '', 0, 0, 0, 0, 1, 6, 1, 1, 0, 1, 1, 1, 'VISIT_WEBSITE', '%s')
The *CPs are detached from the core code (old codeing, still) so no exceptions - which usually are used in controllers.EA117 wrote: ↑Mon Jan 21, 2019 3:44 pm I'm looking at things like Symfony's AccessDeniedHttpException, and I definitely don't know enough to rule out that such a condition could be reported during processing. Due to underlying conditions occurring during internal processing, that are not uniquely or closely related to UCP profile field handling itself.
Thanks for the account activation. Nothing about that phpbb_website profile field data looks unexpected.
Code: Select all
Hypertext Transfer Protocol
HTTP/1.1 403 Forbidden\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 403 Forbidden\r\n]
[HTTP/1.1 403 Forbidden\r\n]
[Severity level: Chat]
[Group: Sequence]
Response Version: HTTP/1.1
Status Code: 403
[Status Code Description: Forbidden]
Response Phrase: Forbidden
Server: nginx\r\n
Date: Mon, 21 Jan 2019 17:13:56 GMT\r\n
Content-Type: text/html\r\n
Content-Length: 1024\r\n
[Content length: 1024]
Connection: keep-alive\r\n
Last-Modified: Wed, 08 Mar 2017 15:34:00 GMT\r\n
ETag: "400-54a39db88f85b"\r\n
Accept-Ranges: bytes\r\n
\r\n
[HTTP response 1/1]
[Time since request: 0.141962000 seconds]
[Request in frame: 69]
File Data: 1024 bytes
Line-based text data: text/html (33 lines)
<HTML>\n
<HEAD>\n
<TITLE>403 Forbidden</TITLE>\n
<BASE href="/error_docs/"><!--[if lte IE 6]></BASE><![endif]-->\n
</HEAD>\n
<BODY>\n
<H1>Forbidden</H1>\n
You do not have permission to access this document.\n
<P>\n
<HR>\n
<ADDRESS>\n
Web Server at n-spoorforum.nl\n
</ADDRESS>\n
</BODY>\n
</HTML>\n
\n
<!--\n
- Unfortunately, Microsoft has added a clever new\n
- "feature" to Internet Explorer. If the text of\n
- an error's message is "too small", specifically\n
- less than 512 bytes, Internet Explorer returns\n
- its own error message. You can turn that off,\n
- but it's pretty tricky to find switch called\n
- "smart error messages". That means, of course,\n
- that short error messages are censored by default.\n
- IIS always returns error messages that are long\n
- enough to make Internet Explorer happy. The\n
- workaround is pretty simple: pad the error\n
- message with a big comment like this to push it\n
- over the five hundred and twelve bytes minimum.\n
- Of course, that's exactly what you're reading\n
- right now.\n
-->\n
modsec_audit.log
Code: Select all
--d5df4c28-A--
[22/Jan/2019:06:26:58 +0100] XEapohE174MvzfMhlXQqWwAAAEw 85.115.60.201 45777 xxx.xxx.xxx.xxx 80
--d5df4c28-B--
GET / HTTP/1.1
User-Agent: curl/7.16.4 (x86_64-pc-linux-gnu) libcurl/7.16.4 OpenSSL/0.9.8o zlib/1.2.3
Host: example.com
Pragma: no-cache
Accept: */*
Via: 1.1 hosted.websense 26d
X-Forwarded-For: 94.23.238.218
Client-IP: 94.23.238.218
--d5df4c28-F--
HTTP/1.1 403 Forbidden
Content-Length: 209
Content-Type: text/html; charset=iso-8859-1
--d5df4c28-H--
Message: Access denied with code 403 (phase 2). String match "HTTP/1.1" at REQUEST_PROTOCOL. [file "/usr/local/apache/modsecurity-owasp-old/base_rules/modsecurity_crs_20_protocol_violations.conf"] [line "399"] [id "960020"] [rev "2"] [msg "Pragma Header requires Cache-Control Header for HTTP/1.1 requests."] [severity "NOTICE"] [ver "OWASP_CRS/2.2.9"] [maturity "6"] [accuracy "8"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client %s] ModSecurity: %s%s [uri "%s"]%s
Action: Intercepted (phase 2)
Stopwatch: 1548134818955753 1634 (- - -)
Stopwatch2: 1548134818955753 1634; combined=158, p1=124, p2=20, p3=0, p4=0, p5=14, sr=36, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.9.1 (http://www.modsecurity.org/); OWASP_CRS/2.2.9.
Server: Apache/2.4.29 (Unix) OpenSSL/1.0.1e-fips
Engine-Mode: "ENABLED"
--d5df4c28-Z--
[id "960020"]
tells you exactly which rule was invokedpf_phpbb_website
argument of phpBB's ucp.php
module to the list of excluded application module arguments this check will be made against. Since "http://" is actually expected in the POST arguments for this module.