AEM/CQ5 (5.6.1) appears to have a deficiency in how content validation works in the out-of-the-box product.
Though component dialogs have a mechanism for validation, the validators only get executed when the dialog is open. The problem is that a component can be added to a page, and without opening the component's dialog, the page can be activated with the unconfigured component. Even worse, it's possible to activate a page without completing mandatory configuration in its page properties dialog.
I have previously dealt with the latter by creating a replication preprocessor (com.day.cq.replication.Preprocessor) which validated the expected page properties. This is suboptimal, since it has its own validation logic, which may diverge from the dialog validators. It also does nothing to validate components on the page.
Is there any way to leverage the validation rules in component dialogs for validating content prior to activation? If not, do you have any other suggestions for improving pre-activation content (page and component properties) validation?
One option can be to define a flag in component dialog which you can use to show visible notification text to configure the component and update it once it is configured.
It actually is more of a knowledge problem than a product issue.
Aem can be configured for non-technical authors who can add/modify content on author instance and then can submit it for Review via workflow.
The reviewer can then verify and replicate content if found to be fine.
Related
In TYPO3 versions before v9, when using the native form, I always disabled the cache of that specific "contact" page (where the form was placed). If I didn't disable the cace, the form wouldn't redirect to my "confirmation" (v6/v7) or "redirect" page (v8), but instead it would simply reload the (filled-out) form (on the same page).
So, to bypass this and to make sure that the form actually got submitted and forwarded to the correct confirmation page, I always disabled the cache (Page Properties -> Page -> Behaviour -> Disable cache).
In TYPO3 v9 however, this option has been removed, and adding config.no_cache = 1 into that specific page (in a TS template), doesn't seem to do the (same) trick.
I would expect that the form, after clicking the submit button, would forward to the confirmation (redirect) page which I configured insde the form itself. That confirmation page isn't usergroup-protected or anything, it's simply a sub-page of the "contact" page (containing the form) itself.
The actual issue in this case is that you are most likely using some kind of autofill for your fields, e.g. from Chrome or using a form filler extension.
This will also fill the honeypot field of your form which then prevents submitting the form.
Right now there is nothing you can do about this except voting for the bug in the Chromium issue tracker.
As Mathias Brodola righfully points out, this seems to be a problem in Chrome only. I found this following plugin - that completely disables autocomplete support for a form - to be helpful in this matter. It solved my issue (however, it does completely disable auto-complete support for the form):
https://github.com/terrylinooo/jquery.disableAutoFill
I created an extension with the extension builder.
On saving I get this message:
The object was updated. Please be aware that this action is publicly accessible unless you implement an access check. See https://docs.typo3.org/typo3cms/extensions/extension_builder/User/Index.html
How can I fix this issue? Yes I read the page but there are no useful hints.
Since the question is how you can "fix the issue": There is no issue, it is a warning, you can remove it and make your request secure. (As in the other answer.)
The "hint" on the page is actually very straightforward. The "issue", that a user is able to manipulate the url and make the server to execute a not wanted action.
Here is an example:
You have a list of users of your page and you can open thier public porfile for more information:
https://yourdomain.com/list/?tx_ext_plugin['action']=show&tx_ext_plugin['userId']=41.
So if I want to make some trouble, I change the action "show" to "delete" and may I am able to delete the poor user "41" from the db. That is bad.
https://yourdomain.com/list/?tx_ext_plugin['action']=delete&tx_ext_plugin['userId']=41.
So since it is you business logic typo3 offers no out of the box solution for this. That is why this warning from extension builder says, that you need to make actions to prevent misuse.
Regarding how to implemnt a better security here are some thoughts about the Access Control and some ideas what to implement in your actions:
1) FE
You can separate your actions into different plugins. So if you have a public list action it can not be modified to the plugin that responsible for the delete action. How is it possible? TYPO3 will look the page record in your database. And will render it, and if there is a plugin on the page with the signature "tx_ext_plugin" then it will get the sent parameters. In this case you have the possibility to add the different plugins to different pages so changing the signature of it for an attacker won't help, because:
If the delete action is not registered by the plugin, TYPO3 will
throw an exception.
If you are trying to change the whole signature the page won't be able to identify the plugin.
You can add the edit / delete plugin to pages where a user has to be logged in. You can even manage multiple usergroups. Like normal user can only edit its profile, but a premium user can make further changes. You can use in fluid a view helper IfHasRole that can show parts of your template for defined user groups. (There is an ifAuthenticated ViewHelper too)
You can take the extension "femanager" as an example. There is a controller "EditController", that covers actions like "update" and "delete". For example before making the update action there is a check if the logged in user has the same user id as the record which going to be changed. If you have a complex example you can make a check on the user group also.
2) BE
It is actually almost the same as frontend.
BUT instead of plugins / user groups assigned in page settings. You can use different mountpoints, so BE users can not see folders where they are not allow to edit / delete.
You have those two ViewHelper for the BE too. There names are: f:be:security.ifAuthenticated and f:be:security:ifHasRole. However ifAuthenticated is also for FE, in a BE context it does not make sense.
You have also the possibility to identify the id and userGroups of the BE user and you can make your own checks before you let an action run.
You have also the possibility to turn on / off a module for a certain BE group.
+1: It is nothing to do with any action but just to list it too. There is also the possibility to allow / disallow field for BE Users by editing a record through the List mode in the BE.
Extension builder creates dummy actions to update and create records. Those example actions do not contain any security checks, whether the caller actually is allowed to do so.
So it is your job to add adequate access control to those methods. E.g. make sure the current user (be it Frontend or Backend) is actually allowed to update the model in question.
So here's the situation and I cannot figure out how to accomplish it.
I have a content type called "Alert". Each instance of this content type needs to have a webform (really just a submit button with hidden fields), that users click to acknowledge they have read and understand the alert. Ideally once submitted, the form should be replaced with a message along the lines of "You have marked this alert as read."
I do have a webform created (displaying as a block to be able to place within the variant page set up for the Alert type) and can get it to appear on each instance, but users can submit multiple times on each alert (submissions are set to unlimited as if i set it to 1 submission per user, the form does not render after the first submission on any alert). Additionally, once they click on one instance of the form, every additional instance will result in a message stating they have already submitted the form.
So I really have two issues. First, and most importanlty, allow a single submission per node (without the "already submitted" notice). Second, not required but would be nice, once it has been submitted for a specific node, the form no longer renders on that node for that particular user. Anyone have any ideas on the best way to accomplish these two aspects?
I'm running on Drupal 7.56, using the AT_Panels_Everywhere theme, Webform module Version: 7.x-4.15.
In drupal 7, with webform 7.x-4.0, you can enable webforms within a content type. To do so:
Go to Structure > Content Types
[Respective content type] > Edit
In the bottom left section, find the Webforms Tab and choose Enable webforms for this content type.
Based on your use case, I'd recommend enabling that and installing the node clone module. Then you can make one alert node, setup the webform, limited to one submission per user and allow content managers to clone content. That node can serve as a template.
My angular application needs to submit a form to a vendor. They then redirect the user to a page that I specified earlier in the process.
So I want standard, non-angular html form submit behaviour.
The documentation (details below) makes it sound like all I need to do is add an action attribute to my form element. I have tried this and it does not work.
Has anyone used this functionality in angular? Is there another step that I am missing?
The relevant section of the documentation at https://docs.angularjs.org/api/ng/directive/form is:
Submitting a form and preventing the default action
Since the role of forms in client-side Angular applications is different than in classical roundtrip apps, it is desirable for the browser not to translate the form submission into a full page reload that sends the data to the server. Instead some javascript logic should be triggered to handle the form submission in an application-specific way.
For this reason, Angular prevents the default action (form submission to the server) unless the element has an action attribute specified.
Angular does that. When you provide an action on the form, it should do exactly what you're trying to do (do a javascript thing, then submit the form).
Here is a plunk
In the plunk, you can see the $scope.submitted say 'submitted' just before the form submission kicks the page over to the submitted.html
How would I go about creating a CAPTCHA plugin for the framework Kentico CMS 7.0?
Is there a predefined webpart called CAPTCHA webpart?
There are few form controls of CAPTCHA type. Navigate to Site manager -> Development -> Form controls and filter out CAPTCHA controls. You'll find e.g. "logic captcha" or "text captcha". You can use those controls e.g. in forms (this is typical usage) or anywhere else (just see properties of particular control).
If you want to prevent robots posting to your forms edit the form, add a text field and select CAPTCHA of your choice as a form control.
In addition to the built in CAPTCHA controls, you can also build your own reCAPTCHA control rather easily. The instructions are listed on this Kentico DeveNet forum post. Note that for step 5, instead of using the code listed in the first post, use the code in my reply to the initial post ('Gavin_Paolucci-Kleinow-URMC.Rochester - 1/4/2013 11:05:53 AM' since I can't link to that individual post in the thread).