Facebook
Twitter-
Hi, Pleskians! We are running a UX testing of our upcoming product intended for server management and monitoring. We would like to invite you to have a call with us and have some fun checking our prototype. The agenda is pretty simple - we bring new design and some scenarios that you need to walk through and succeed. We will be watching and taking insights for further development of the design. If you would like to participate, please use this link to book a meeting. We will sent the link to the clickable prototype at the meeting.
-
Our UX team believes in the in the power of direct feedback and would like to invite you to participate in interviews, tests, and surveys.
To stay in the loop and never miss an opportunity to share your thoughts, please subscribe to our UX research program. If you were previously part of the Plesk UX research program, please re-subscribe to continue receiving our invitations. -
The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
Resolved 403 - Forbidden: Access is denied for PUT and PATCH Request
- Thread starter AV0408
- Start date
-
- Tags
- .net core 7 web api
hitesh-wappnet
New Pleskian
I got the similar issue in my Nest JS API. PUT,PATCH,DELETE methods gives 403 - Forbidden error.
Solution :
Go to Plesk -> 'Tools & Settings' -> Web Application Firewall (ModSecurity) -> Settings
- Rule set : Atomic Standard
This worked for me.
Solution :
Go to Plesk -> 'Tools & Settings' -> Web Application Firewall (ModSecurity) -> Settings
- Rule set : Atomic Standard
This worked for me.
Switching the ruleset might not be necessary. For one case, another ruleset might work, but it may create false positives in other cases.
Instead, examine the error_log entry where the 403 error is logged. It will mention an [ID .......] field. This is the rule ID that triggered the 403 block. You could at it as an exception to the rule exceptions in the "Web Application Firewall" dialog page.
Instead, examine the error_log entry where the 403 error is logged. It will mention an [ID .......] field. This is the rule ID that triggered the 403 block. You could at it as an exception to the rule exceptions in the "Web Application Firewall" dialog page.
hitesh-wappnet
New Pleskian
Okay, I have again enabled Rule set : OWASP . In my case, I have deactivated 'OWASP_CRS' Rule and everything is working as expected.
Thank you for the correct solution.
Thank you for the correct solution.
