How call AEM Servlet in JSP's form tag not via Ajax

If you are on 6.1 version then I think the POST request is being blocked by the CSRF filter. And to resolve this you should include the CSRF javascript on the page which will automatically inject the CSRF token parameter in your form before submitting it.  You can confirm whether this request is blocked by CSRF or not by disabling the CSRF check on POST request temporarily - http://localhost:4502/system/console/configMgr/com.adobe.granite.csrf.impl.CSRFFilter

Check the following documentation - https://docs.adobe.com/docs/en/aem/6-1/develop/security/csrf-protection.html

Sameer,

It seems you are posting the data at the root node. And, The logged-in user does not have permission to add/create/update at the root node of the repository.

Is your servlet registered?.

Jitendra

Hi Jitendra,

Yes servlet is registered. we are not adding at root level. we are trying to to drop the assets via dropzone and calling the servlet.

Thanks

~S

Do you see any errors in the error.log file when you submit the form ?

Also,  instead of checking the checkbox in the CSRF configuration you should just remove the POST string from the Filter methods by clicking on the minus button.  

May I have error.log & your servlet code which returns forbidden message to the caller. By the way, When do you return forbidden response from the servlet?. Is it something on catch block?.

Jitendra

Hi

Please have a look at the post, it is almost synonymous to problem.

Link 1:- http://tiku.io/questions/4120715/cq5-403-forbidden-occurs-when-call-a-post-servlet

//CQ: 403 Forbidden occurs when call a Post servlet

As mentioned at http://sling.apache.org/documentation/the-sling-engine/servlets.html, a servlet using the sling.servlet.paths property might be ignored unless its path is included in the Execution Paths (servletresolver.paths) configuration setting of the SlingServletResolver service. You should find that configuration at /system/console/configMgr/org.apache.sling.servlets.resolver.SlingServletResolver .

In your case I suppose the /bin/mySearchServlet path is not included in that configuration parameter and causes CQ to return a 403 status. If that's right you can either add your path there (assuming you understand the security implications) or mount your servlets on one of the paths that's configured there.

Note that it's best to avoid mounting servlet on paths if possible, creating a resource at the desired path is preferred as mentioned on that documentation page.

Link 2:- https://forums.adobe.com/thread/1120136?tstart=0

//

it is enough if you are using this kind of annotation like in your example code - maybe better is to used instead of "POST" selector some other name for it

@Component(immediate = true, metatype = false, label = "QuestionnaireServlet")

   @Service

   @Properties(value = {

                    @org.apache.felix.scr.annotations.Property(name = "sling.servlet.methods", value = { "POST" }),

                    @org.apache.felix.scr.annotations.Property(name = "sling.servlet.resourceTypes", value = { "sling/servlet/default" }),

                    @org.apache.felix.scr.annotations.Property(name = "sling.servlet.selectors", value = { "POST" }),

                    @org.apache.felix.scr.annotations.Property(name = "sling.servlet.extensions", value = { "html" })

   })

if you want to check if your servlet is registered, try to open Apache Felix Console, expand a bundle and there you should have listed your servlet as a service

About B

this node should not exists in the repository

Please also delete bundle form the Apache Felix Console and try to install it again and see if the servlet will be registered as a service

I hope this would help you.

Thanks and Regards

Kautuk Sahni    

kunal23 wrote...

Also,  instead of checking the checkbox in the CSRF configuration you should just remove the POST string from the Filter methods by clicking on the minus button.  

Even for local development this shouldn't be recommended incase this config flows through to production. CSRF only comes into play for authenticated users. Is your test user logged in?

Yes I agree. Thats why in my first answer, I suggested to remove this configuration temporarily to check whether the request is indeed blocked by CSRF or not. The ideal solution is to include the CSRF javascript on the form page which passes the token along with the form data.