EDIT: the answer of #Wolffc is totally correct - i had a false return value so the problem was between chair and screen.
TYPO3 10.4.8
I’m generating a link in a Mail with <f:link.action> to validate a subscription to a Course.
It must not be cached, so i can check if the link is already clicked, but there is a cHash added to the link.
<f:link.action
action="validate"
pluginName="Coursevalidation"
extensionName="myextension"
controller="Course"
pageUid="1"
absolute="1"
pageType="1921"
noCache="1"
noCacheHash="1"
arguments="{validationHash: subscription.validationHash, course:course, subscription:subscription}"
>Link</f:link.action>
the documentation says noCache and noCacheHash should not be used (“you should not need this”), and it makes no difference if I add it.
The PageType is uncached, 1921.config.no_cache = 1
The generated link results in (linebreaks for better readability):
https://mydomain.ddev.site/email-validation
?no_cache=1
&tx_myextension_coursevalidation%5Baction%5D=validate
&tx_myextension_coursevalidation%5Bcontroller%5D=Course
&tx_myextension_coursevalidation%5Bcourse%5D=3
&tx_myextension_coursevalidation%5Bsubscription%5D=30
&tx_myextension_coursevalidation%5BvalidationHash%5D=40e83[...thats long ;)...]0d65c
&cHash=5d7688ac4f04a2d31a98f2cffb792e51
As you can see, theres a cHash.
First klick on the Link triggers my mechanism to check everything and set the subscription to valid , and redirect to the “Success”-Page, what is exactly what it should do.
The second klick opens the success-page too, but there should be the message “Already validated”.
That page is opened, when I call the Link without the cHash.
Why is there a cHash added and how can I remove it?
Thanks :)
You must define this action as uncached in ext_localconf.php
TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin
If the plugin action is uncached typo3 will handle that correctly.
The cHash is a checksums over the request parameters and is mainly used to prevent cache bloat attacks. If an attacker generates random parameter sets. If cHash is invalid. The result will not be cached. But the reverse is not true. If cHash is valid it might still be that the parts of the page uncached. (Or even the whole page)
Related
According to http://www.typo3-probleme.de/2018/07/11/typo3-sitemap-mit-typoscript-erstellen-2285/ I let TYPO3 V8.7.24 generate the sitemap.xml file. So far it works. But in the file there are not proper URL's. On every URLs end is "?type=500001", for example an URL looks like "https://www.domain.ch/angebot/online-marketing/?type=500001". As a side note , there is also Ext:Realurl in use.
My request is, how can you remove the segment "?type=500001" ? Is the reason typoscript or the extension Realurl? How can I analyse it?
Any hint is welcome. Thanks in advance for your help.
It's the link generation inside of TYPO3. that is configured by typoscript, so you could see typoscript as the culprit.
If you want to know whether realurl (or any other extension) is the culprit: disable the extension in mind. if the error is gone there is a reason to suspect this extension.
When links are generated by TYPO3 it holds some parameter to stay in the current context. Which paramaters should be considered is a configuration (so it is grounded in typoscript).
Have a look (TSOB) at config.linkVars in general (it is copied implicit to every page object) or of your page object page.config.linkVars (in your case: xml_sitemap.config.linkVars)
There is a note in the manual:
Do not include the type parameter in the linkVars list, as this can result in unexpected behavior.
Other option would be to explicit set &type=0 to every link. But don't forget to set config.uniqueLinkVars = 1 (or xml_sitemap.config.uniqueLinkVars = 1)
One of our customers wants to add a terms of service page that has to be shown every time a user adds some specific content type, before the add form.
Any suggestions on how to implement this?
If it's a Dexterity content type, you can do this:
Create a custom form with your terms of service. In the form's button handler, redirect to the add form:
self.request.response.redirect(self.context.absolute_url() + '/++add++name.of.content.type')
Now in your type's factory info in portal_types, set the add_view_expr like this:
<property name="add_view_expr">string:${folder_url}/##terms-of-service</property>
so it goes to the custom TOS form when you click the type in the factory menu, instead of directly to the add form.
(Note: a downside of this approach is that if the user enters the URL of the add form directly, they can bypass the TOS form.)
A possible solution could be to use a cookie/session_data_manager/token/you-name-it that on the custom AddForm for that content type checks if exists.
If it doesn't redirect to that Terms of Service form that redirects back to the Addform where, now it will accept to proceed becuase the cookie/session_data_manager/token/you-name-it will be there.
An idea: when you are adding new content types (AT based content types, this will not work for Dexterity ones) you are calling
http://something/createObject?type_name=Document
You can transform the createObject script into an view that display you disclaimer form, with validation on submit.
When user accept the disclaimer you will redirect the use to something like
http://plone4.gest.unipd.it:8080/gest/it/realCreateObject?type_name=Document
where realCreateObject is a copy/paste of the original Plone createObject script.
However: the suggestion of Mathias above is really good: just add a fake checkbox field with a validation.
As mentioned in the comment of the question. I would advise adding a checkbox to the content.
For AT content you can add a BooleanField
...
atapi.BooleanField(
name='acceptConditions',
schemata='default',
required=False,
default=False,
validators=('acceptConditions', ),
widget=atapi.BooleanWidget(
label=_(u'label_accept_conditions', default='Conditions'),
description=_(
u'help_accept_conditions',
default='Please accept the <a target="_blank" '
'href="./conditions_view">'
'conditions<a/>.')
),
)
...
With a condition on the widget (In this case a browser view, which checks if the boolean field should be visible or not).
YourSchema['acceptConditions'].widget.setCondition(
'python: here.restrictedTraverse("##show_condition_field").show()')
Fortify scan caught this below error as critical. can some please help ?
switchcontent.loadpage=function(page_request, header){
var innercontent=document.getElementById(header.id.replace("-title", "")) //Reference content container for this header
innercontent.innerHTML=switchcontent_ajax_msg //Display "fetching page message"
if (page_request.readyState == 4 && (page_request.status==200 || window.location.href.indexOf("http")==-1)){
innercontent.innerHTML=page_request.responseText
header.ajaxstatus="loaded"
}
}
what change would be needed to fix this code for avoiding XSS ? Any help is greatly appreciated. thank you.
In the responseText are HTML tags inserted or is it just text you want to insert/change? s a rule of thumb always sanitize/encode all user input and output that is generated from user input. If it's only text that you're inserting use document.createTextNode (example) and append the text to the element's needed (always encoded also), I would recomend using jQuery .text() as with pure javascript it's kind of cumbersome. If it's HTML that is needed to be inserted be sure it's not user input as this is a vulnerability. If the text needs to be from a user use a whitelist to check that the user is only writing tags that you are expecting for example <p></p>.
Fortify treats this as a vulnerability because if a user sends in the responseText <script>alert('XSS')</script> the page will render this as HTML and the script will be executed if you encode this it would just appear as text and not be executed, not only scripts can be executed but HTML will be rendered also and deform your page. You can read more in: OWASP DOM Prevention Sheet
Points:
1: ALWAYS ENCODE USER INPUT!
2: If it's just text create text nodes and append them to the element to make this easier use jQuery if possible function .text() not .html() as the .htlm() function will render the HTML.
3: If it's user generated HTML sanitize malicious tags agains a WHITELIST you can do blacklist but blacklists are not that safe as there are always tags you could forget to check against.
4: If the HTML is server generated and has not user input you should be fine.
5: Know that Fortify is just a scanning tool and it has false positives, so if you have the right countermeasures you should be XSS free.
Whitelisting: Checking agains a list of available tags. Only letting tags that you know the user can use like <p></p><br/>.
Blacklisting: Checking against a list of "not welcome" tags. This means having a list with tags you don't want to let the user use.
I would like to upgrade one of my joomla 2.5 plugin (self-developed). It is a complex task, but here is this specific issue I couldn't solve. I would like to put an input field with a submit button at my articles (done), and after submitting I want to get it. So simple.
Here is the outline of the code:
The form:
<form action="" method="post">
<input type="text" name="info">
<input type="submit" value="ok">
</form>
The process:
$jinput = JFactory::getApplication()->input;
$foo = $jinput->get('info', '444');
print_r($foo);
Basically it should work, but somehow I don't get the value, always recive the default value '444'. If I change the action to an external php file, and process in php-way, it works.
What I checked so far:
a. change form method to GET. Result: the needed value appears properly in the article's URL, but still print the default value '444' not the value I see in the URL (if the default value isn't set, it doesn't print anything).
b. pass the value to an external .php file, store in session, and echo the session value in the article, but empty again.
Maybe I will force to get the GET values by exploding the $_SERVER["REQUEST_URI"], but I can't sleep until I find out what could be wrong with desired process.
Anyone can help?
UPDATE: maybe important - I use K2 plugin.
So far I could figure out the following:
it is a special case. On my local server the code works fine both with normal joomla articles and K2 component articles.
on my website the code also works fine with normal joomla articles, so it is defenietly a K2 settigns-issue.
there was a chance the problem is related to K2 advanced SEF settings (specifies the url of the K2 item), but it isn't. The problem is on my website, so I used on my localhost-version the SEF settings of the website-version, and I recived the values fine. == not K2 advanced SEF settings problem.
This is the answer for my question: "should find which K2 setting is causing the problem"
UPDATE. Solution: turn off caching at global configuration, so the page isn't loading from cache. In cache are no given values stored - obbbbbviously.
I'm creating my form using the Form helper, so the action of the form is specified automatically....
this form is used for editing a post..
so, the URL has the structure: mywebsite.com/posts/edit/id
and the form's action should be automatically generated as posts/edit/id
but the problem is, in some cases, I open the HTML code and I find that the form's action is only posts/edit without the id which causes the update to fail...
I spent a lot of time to figure out what situation brings this wrong action:
i'm generating fields dynamically (using javascript & ajax) depending on the post's category..
when the value of one of the dynamically generated fields is invalid, the generated action becomes posts/edit !!
I really need help, cuz I don't know why this is happening !!!
and I don't wanna waste more time digging into the core of cakephp...
so, if any of cakephp experts has an idea about this, plz help me !!
thank you in advance !
Use the url parameter, which allows you to explicitly define a url for the form:
echo $form->create('Post', array('url' => $html->url(array('action'=>'edit', $id))));
It sounds like $id probably isn't getting set, because it should be getting passed along if it is. You need to make sure it's set to edit the record in question. Make sure your javascript is including the hidden field with the record's id in it.
Normally done like this, with the form helper: echo $this->Form->input('id');
Also, if one of the fields is invalid, the form shouldn't actually be submitting properly, if you are using cake's validation, so this is to be expected.