I am working on a project in Zend Framework 1.12. I want to build a facility that will enable members to dynamically upload a VCSS stylesheet of their choice; thus enabling them to format the page in the colour of their choice. The parameters to their stylesheet is load via the URL;
i.e
The url could be like this: samplewebbsite/?s=rootfolder/stylesheet
we collect it with: $this->view->stylesheet = $this->_request->getParam('stylesheet', ' );
The getParam() gets the distination to their style sheet. i.e: rootfolder/stylsheet.css
I then display the value on the index page i.e:
<link href="<?= $this->stylesheet ?>" media="screen" rel="stylesheet" type="text/css" >
My question now is this: I want to protect the getParam() from javascript/sql injection/bad code etc. How do I protect it? Should I use strip_tags() or is there a better way to protect it?
i think i worked out how to do it; i did this; i simply used strip tags.
$this->view->stylesheet = $stylesheet = strip_tags ($this->_request->getParam('s', ''));
i tried to use the
$alpha = new Zend_Filter_Alpha();
$this->view->stylesheet = $alpha -> filter($this -> _request -> getParam('name'));
But i found that it was also taking out all the break lines i.e the http /:Sameplesite/Rootfolder/ became samplesiteRootfolder
if anyone has a better solution, i would be keen to hear ( ie i would have preferred to use the filter class). but otherwise. i think that my question is pretty much answered.
Related
If an uncached page is called in the frontend with a GET parameter that is not foreseen and has been appended to the URL from a link of an external source, like a tracking parameter or something worse e.g. …
https://www.example.com/?note=any-value
… then this foreign parameter is passed on in the automatically generated canonical tag, created by TYPO3's core extension ext:seo. It looks like this:
<link rel="canonical" href="https://www.example.com/?note=any-value&cHash=f2c206f6f14a424fdbf82f683e8bf383"/>
In addition, the page is saved in the cache with this parameter. This means that subsequent visitors will also receive this incorrect canonical tag, even if they call up the page https://www.example.com/ without the parameter.
Is this a bug (tested on TYPO3 10.4.15) or can it be disabled for all unknown parameters by configuration?
If you know the parameter, you can exclude it in the global configuration …
[FE][cacheHash][excludedParameters] = L,pk_campaign,pk_kwd,utm_source,utm_medium,…
… or via ext_localconf.php in the sitepackage:
$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['excludedParameters'][] = 'tlbid';
I am only concerned with parameters that were not expected. It might make sense to turn the concept around and basically exclude all parameters except for a few self-defined allowed parameters, but I don't know if that is possible so far.
Got it. Actually, TYPO3 handles these already for other common tracking and additional params, like L, utm_campaign, fbclid etc. The whole list of excluded params can be found in the source code.
To add your own, just add/modify the typo3conf/AdditionalConfiguration.php file i.e. just like:
<?php
$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['excludedParameters'][] = 'note';
$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['excludedParameters'][] = 'foo';
$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['excludedParameters'][] = 'bar';
or
<?php
$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['excludedParameters'] = array_merge(
$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['excludedParameters'],
['note', 'foo', 'bar'],
);
Don't forget to clear caches after all :D (that should be a TYPO3's slogan)
It's a bug. The extension urlguard2 solves this issue.
it dont work for me in the TYPO3 V11.5.16
LocalConfig:
[FE][cacheHash][excludedParameters] = L,tx_solr,sword_list,utm_source,utm_medi…
Browser URL:
https://www.example.org/testfaelle/test?sword_list%5B0%5D=testf%C3%A4lle&no_cache=1
The HTML Frontend canonical is:
<link rel="canonical" href="https://www.example.org/testfaelle/test?sword_list%5B0%5D=testf%C3%A4lle&cHash=e81add4ca148ad10189b9cbfa4d57100">
Debugging:
if i go in the file: "/typo3/sysext/frontend/Classes/Utility/CanonicalizationUtility.php" and add the Parameters directly: $paramsToExclude[] = 'sword_list'; ist works:
<link rel="canonical" href="https://www.example.org/testfaelle/test">
A proposed change to the Content Security Policy (CSP) of our web server to disallow inline script
is causing a problem with the documentation generated by doxygen. Specifically, the problem occurs
in the generated index.html file, and the following lines:
<!-- Generated by Doxygen 1.8.15 -->
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* #license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
$(function() {
initMenu('',false,false,'search.php','Search');
})
/* #license-end */</script>
If the initMenu() code is put into a separate file that is just included like other JavaScript files, everything
works just fine. Is there a doxygen option to put all JavaScript into files rather that inline? We can
post process the generated file to do this, but may not know when the "pattern" of this code may
change due to updates in doxygen itself. And we may not know if using additional doxygen features will result in other inline JavaScript.
Any suggestions would be welcome.
Thank you
Fritz Sieker
First off Content Security Policy is useful but far from being an absolute authority. There are other completely useless headers such as those that block referrers based on "privacy".
Secondly there is no such thing as "text/javascript", perhaps they meant application/javascript?
If you're using good (though very non-common practices) you don't have any script elements in the body element (use defer="true" on script elements in the head). By doing that you'll better understand the structure of JavaScript and that in turn will help you become more proficient/capable/help more people/make more money/etc.
You can use document.getElementsByTagName('body')[0].getElementsByTagName('script') to find all the script elements in the body element that don't belong there.
If you do have script elements in the body element beforehand and moving them to the head element is not feasible right now you're likely going to have to work with inherent logic, in short those script elements will always be inserted in to the DOM in a specific and reasonably easily reproducible area of your code (like as the very last elements). In such a case you can find them via the following:
document.getElementsByTagName('body')[0].lastChild
document.getElementsByTagName('body')[0].lastChild.previousSibling
document.getElementsByTagName('body')[0].lastChild.previousSibling.previousSibling
Keep in mind that pressing Enter in your code to make it more readable will insert a textNode so you may want to append nodeName to those instances and look for "script":
console.log(document.getElementsByTagName('body')[0].lastChild.nodeName);
There is the DOM TreeWalker that might help you out here, subjective to the end result in your DOM. I don't know offhand if you can transverse all the elements in reverse (probably).
Once you know what you want to delete instead of making everything convoluted just send that object (or id) to the following:
function element_del(id)
{
if (typeof id=='string' && id_(id) && id_(id).parentNode.removeChild)
{
id_(id).parentNode.removeChild(id_(id));
}
else if (typeof id=='object' && typeof id.parentNode=='object') {id.parentNode.removeChild(id);}
}
//Example:
element_del(document.getElementsByTagName('body')[0].lastChild);
I hope this helps!
Imagine the question: "Please write down five titles of TV Series".
We want the answer to be spontaneous thus the users freely recall and write their answers such as "Game of Thrones", "The Big Bang Theory" or "Friends".
Our problem is that some of them will write "big bang theory", others "The Big Bang Show" or even "big ban teory" but we know that these answers are the same.
Therefore, we would like LimeSurvey to dynamically offer an auto-completed answer like "The Big Bang Theory" to all of them so that we minimize the manual work of rewriting and grouping the answers.
Is this feature available? If not, do you have any clue about how to implement it?
LimeSurvey (and don't think any other system) don't have core system to do this. But LimeSurvey include jquery-ui, and jquery-ui have autocomplete.
Something like this (if you have a csv file).
download jquery.csv-0.71.js at https://code.google.com/p/jquery-csv/ and put it in your template directory.
put your csv file in your template directory (name series.csv : one serie by line)
Update the HTML sourve of your question with:
<script type="text/javascript" src="{TEMPLATEURL}jquery.csv-0.71.js"></script>
<script>
var url = "{TEMPLATEURL}series.csv";
$(function() {
var seriesTitle = new Array();
$.get(url,function(data){
fullArray = $.csv.toArrays(data);
$(fullArray).each(function(i, item){
seriesTitle.push(item[0]);
});
$("#question{QID} input[type=text]").autocomplete({
source: seriesTitle
});
});
});
</script>
It work for multi text and short text.
If needed you can use an API (and if available).
Look at autocomplete exemple to see using JSON : http://jqueryui.com/autocomplete/#remote
I'm writing a plugin which should add HTML to the page's head area (inludeJS to be exact). Something like this should work:
page.includeJS {
tx_myplugin_pi1 = EXT:my_plugin/pi1/tx_myplugin_fe_scripts.js
}
The problem with that is that I have to assume that "page" would be the universal name used for the page object I want to work with. Since the name of this variable can be anything I would like to do this in a more intelligent way than this.
Is there a way to determine the name of the current PAGE cObject I'm working with?
cu
Roman
You can find out the default PAGE object of the current page using this snippet:
$setup = $GLOBALS['TSFE']->tmpl->setup;
foreach(array_keys($setup) as $key){
if(substr($key, -1) == '.'){
if($setup[substr($key,0,-1)] === 'PAGE' && intval($setup[$key]['typeNum']) === 0){
print substr($key,0,-1) .' is the default PAGE object';
}
}
}
But this won't help you to add the Javascript in the frontend, as the typoscript is being parsed already at that point.
If you want to add the javascript just for your extension I would recommend using:
$GLOBALS['TSFE']->additionalHeaderData['tx_yourextension_plugin'] = '<script type="text/javascript" src="' . t3lib_extMgm::siteRelPath('my_plugin') . 'pi1/tx_myplugin_fe_scripts.js"></script>';
(this wouldn't be merged with the other JS files though)
Actually there is no such way in plain TypoScript. As most installations are using page as keyword - especially those which are under your control - it is really fine to use it.
If you are writing an extension, you can put that into the documentation as a small hint!
I have been using plain forms and input fields in coldfusion for some time now but recently discovered that cfinput tags will automagically prevent some xss attacks for me. This has made me wonder, if there is any disadvantages to using cffrom and cfinput over normal form and input tags in coldfusion.
The only disadvantage I have found in the short time looking into it is that it adds 2 external style sheets and 1 script tag to the page.
so in short:
What are the advantages and disadvantages of using CFFORM over FORM in coldfusion?
I prefer to write my own JS around my forms. I started out with cfform back in the day, but eventually wanted to do more robust things (validations, etc) than cfform was able to handle. That forced me to learn JS, and I've been very happy writing my own JS since.
So I guess I'd say one big drawback is that you're restricted to what cfform can handle. Depending on your situation, that might be fine.
Another drawback that I ran into a long time ago (which to be fair, may have been addressed since), is that the JS generated by cfform would conflict or interfere with my hand-written JS.
It'll certainly come down to preference. It's neither "right" nor "wrong" to use cfform or regular forms. For me, I prefer to be able to do whatever manipulation I need to do manually, as there are no restrictions/limitations.
I have a love-hate relationship with <cfform> & <cfinput>.
To have the same xss protection that CFFORM provides, just wrap htmlEditFormat() around value="" in regular like so:
<input name="x" value="#htmlEditFormat(x)#">
For even better XSS protection, use OWASP Enterprise Security API (.jar included in one of the CF9 latest hotfixes)
I love how I can do ajaxified form easily without writing JS, but I hate how it generates lots of ugly JavaScript and loads up lots of JS and css files for something rather simple. So I've decided to use cfform for internal sites only and not for public facing site (performance issue).
Other then the ajax features, the checked attribute that accepts CF boolean and populating select with query object are features that cfinput and cfselect provide which can be quite useful.
Use the right tool for the right job. If you found the feature of <cfform> useful, use it. Just know its limitations, and decide for yourself.
I have been using ColdFusion for almost 14 years. The reason that CF is such a kick-ass product is that empowers new users to get a lot of work done quickly with not much understanding and it enables rocket scientists to build really powerful and secure applications quickly too.
CFFFORM, CFINPUT, CFLAYOUT, CFPOD are tags that are created for new users. Basically, they are training wheels. If you're new to web development, you should give this tags a try. As you gain experience, you'll want to drop these tags and move onto other techniques to create more robust applications.
There's nothing wrong with these tags, just like there's nothing wrong with training wheels. You just need to know that there's an appropriate tool for each job. Actually, there are lots of appropriate tools for each job.
Currently, I am developing a ColdFusion 9 / jQuery / SQL Server intranet that builds external web sites. I am doing it without using a single form tag. And, I am doing it completely in CFSCRIPT. Whoa!
Using jQuery, you don't need forms. You just need inputs. Here's how I create an input in CFSCRIPT.
<cfscript>
Options = "";
for (i = 1; i lte 10; i++) {
Options = Options & wrapOption("Some choice #i# ", i);
}
SelectBox = wrapSelect(Options, "MySelectID");
writeOutput(SelectBox);
SecretDiv = wrapDiv("", "", "MyDivID");
writeOutput(SecretDiv);
</cfscript>
The user defined functions to create the HTML are in my UDF_Library.cfm file:
// WRAP SELECT
function wrapSelect(SelectContent, Class, ID) {
LOCAL.SelectContent = ARGUMENTS.SelectContent;
LOCAL.Properties = "";
// CLASS
if (isDefined("ARGUMENTS.Class")) {
LOCAL.Properties = LOCAL.Properties & " class='#ARGUMENTS.Class#'";
}
// ID
if (isDefined("ARGUMENTS.ID")) {
LOCAL.Properties = LOCAL.Properties & " id='#ARGUMENTS.ID#'";
}
LOCAL.Item = "<select #LOCAL.Properties#>#LOCAL.SelectContent#</select>";
return LOCAL.Item;
}
// WRAP OPTION
function wrapOption(Content, Value, Selected) {
LOCAL.Content = ARGUMENTS.Content;
LOCAL.Properties = " value='#ARGUMENTS.Value#'";
// SELECTED
if (isDefined("ARGUMENTS.Selected") and (ARGUMENTS.Selected eq "selected")) {
LOCAL.Properties = LOCAL.Properties & " selected";
}
LOCAL.Item = "<option #LOCAL.Properties#>#LOCAL.Content#</option>";
return LOCAL.Item;
}
// CREATE DIV
function wrapDiv(Content, Class, ID) {
LOCAL.Properties = "";
// CLASS
if (isDefined("ARGUMENTS.Class")) {
LOCAL.Properties = LOCAL.Properties & " class='#ARGUMENTS.Class#'";
}
// ID
if (isDefined("ARGUMENTS.ID")) {
LOCAL.Properties = LOCAL.Properties & " id='#ARGUMENTS.ID#'";
}
LOCAL.Item = "<div #LOCAL.Properties#>#ARGUMENTS.Content#</div>";
return LOCAL.Item;
}
I use jQuery and refer to every element by its class or ID. If you do that, you can submit the data in each element to an ajax call like this:
<script type="text/javascript">
$(document).ready(function() {
$("#MySelectID").change(function() {
MyID = $("#MySelectID").val();
$("#MySecretDiv").load("CoolQuery.cfm?UserID"+MyID);
});
});
</script>
The point is, that as long as you are using CFFORM and CFINPUT, you can't do all the really powerful jQuery stuff. But, you need those tags to get started.
2012 is going to be a kick-ass year for the power of ColdFusion and jQuery!!!
Good luck!
I haven't used ColdFusion's CFInput in a long while. I've been using the jQuery Validation plugin so that I can perform validation on other things like:
is the element visible? (ie, hide a section if not essential, but eliminate the requirement if not shown.)
is a checkbox checked? (ie, you checked "other", now fill-in-the-blank is required.)
is it a valid date/time value? (ie, I additionally use the DateJS library to assist in this)
perform ajax query to determine if username is unique
is the URL entered valid?
compare password1 with password2
custom rules based on a combination of things
Most validation rules can be added inline to the class parameter:
<input type="text" name="Name" class="required">
<input type="text" name="Birthdate" class="required date">
<input type="text" name="Email" class="required email">
<input type="text" name="Website" class="url">
I prefer to use jQuery because sometimes I need to add this same logic to a non-ColdFusion based form and I don't have to worry about the fact the CFInput is a ColdFusion-Only tag.
Here's a link with more information regarding the jQuery Validation library:
http://bassistance.de/jquery-plugins/jquery-plugin-validation/