I am creating a Joomla component and one of the pages contains a form with a text input for an email address.
When a < character is typed in the input field, that character and everything after is not showing up in the input.
I tried $_POST['field'] and JFactory::getApplication()->input->getCmd('field')
I also tried alternatives for getCmd like getVar, getString, etc. but no success.
E.g. John Doe <j.doe#mail.com> returns only John Doe.
When the < is left out, like John Doe j.doe#mail.com> the value is coming in correctly.
What can I do to also have the < character in the posted variable?
BTW. I had to use & lt; in this question to display it as I want it. This form suffers from the same problem!!
You actually need to set the filtering that you want when you grab the input. Otherwise, you will get some heavy filtering. (Typically, I will also lose # symbols.)
Replace this line:
JFactory::getApplication()->input->getCmd('field');
with this line:
JFactory::getApplication()->input->getRaw('field');
The name after the get part of the function is the filtering that you will use. Cmd strips everything but alphanumeric characters and ., -, and _. String will run through the html clean tags feature of joomla and depending on your settings will clean out <>. (That usually doesn't happen for me, but my settings are generally pretty open to the point of no filtering on super admins and such.
getRaw should definitely work, but note that there is no filtering at all, which can open security holes in your application.
The default text filter trims html from the input for your field. You should set the property
filter="raw"
in your form's manifest (xml) file, and then use getRaw() to retrieve the value. getCmd removes the non-alphanumeric characters.
Related
In Grafana I've got a table panel which contains some names (one each row), that, if clicked, open a new window on Kibana passing via URL the name the user clicked (${__cell}) in order to Drill-Down that particular name.
This use to works fine, but I'm facing a problem when then name contains a special character such as "Identita' Digitale" (without double quote): as you can see it contains an apostrophe/single quote that breaks the query so the Kibana's URL becomes uncomplete.
Try
${__cell:lucene}
instead of
${__cell}
All special characters should be escaped for Lucene query. Actually, you need URL encode for your case - you may try other advanced formatting options.
Doc: http://docs.grafana.org/reference/templating/#advanced-formatting-options
Another dirty hackish solution, use JS to urlencode link in the onclick event, add this string at the end of your link definiton in the Grafana:
" onclick="location.href=encodeURI(this);
So in full HTML it will create link:
<a href="<URL>" onclick="location.href=encodeURI(this);">...
Syntax in my example can be wrong, it may need some minor changes to work properly. You can use jQuery in theory.
First, I'm using Swift. Second this line works fine in my code:
let didIt = fileManager.moveItemAtURL(originalFilePath, toURL: newFilePath, error: nil)
...as long as there are no special characters in the newFilePath. if the newFilePath has a dollar sign or an ampersand ($, & ) in it, the line fails. My issue is that the newFilePath comes from a text field in a window where the user can type any old thing. How do I escape special characters, or encode them so they will pass the test and be included in the new filename?
thanks in advance for any pointers.
My issue is that the newFilePath comes from a text field in a window where the user can type any old thing.
Right there is your problem. Why are you not using an NSSavePanel for letting the user select a name under which to save a file?
If you insist on taking input from a text field, the docs for -URLByAppendingPathComponent: specifically say that the path component string should be "in its original form (not URL encoded)" (emphasis mine).
How did you originally create newFilePath, before appending the path component? For example, you should have used one of the methods with "[fF]ileURL" in the name.
I need to translate in my ini file a word that has a "()" or an "/" sign but it seems to brake when I do it.
eg.
sometext(text)="otherLanguagetext(text)" <-- this causes an error in the ini file an brakes all translations.
sometext/text = "someOthertext/text" <-- Broken also
having spaces work correctly:
Some text="Some text1" <--Works
The fact is that the original language is database generated and doesn't have any translation tag or something like joomla translation tag.
I just type the word I want to translate in this way.
I searched for an ini editor that might fix this out automatically (e.g place '/' or something ) but I had no luck on this.
Your example key's are invalid. INI files by definition can not have any of these characters: ?{}|&~![()^" in the keys.
Note: There are reserved words which must not be used as keys for ini
files. These include: null, yes, no, true, false, on, off, none.
Values null, off, no and false result in "". Values on, yes and true
result in "1". Characters ?{}|&~![()^" must not be used anywhere in
the key and have a special meaning in the value.
— http://www.php.net/manual/en/function.parse-ini-string.php
Joomla language files also have their own specification, which if not followed will cause an error when Joomla loads and parses the language file.
In INI files and Joomla language files the value also has special interpretations for specific characters and requires escaping for the use of some characters like double quotes etc.
Finally, Joomla has language overrides that allow the end user to override any string set by the core software or third party extensions which also affect the way keys are translated.
Try to use backslash before those symbols like this:
"otherLanguagetext\(text\)"
"someOthertext\/text"
P.S. you cannot use ANY special symbols in your constants! Try to name them something like this:
OTHER_LANGUAGE_TEXT
SOME_OTHER_TEXT
Try this,
SOME_TEXT = "otherLanguagetext(text)"
SOME_OTHER_TEXT = "someOthertext/text"
Hope it works
I have a link in an apex report which takes the user to different page, and it passes some values to the new page. The button is set to a url because there are too many items being passed, but I don't think that would matter anyway:
f?p=&APP_ID.:27:&SESSION.::&DEBUG.::P27_1,P27_2,P27_3,P27_4,P27_5:0,#1#,#2#,#3#,#NULL#
The #1#, etc. are columns being passed. Everything seems to work correctly except that the data being passed often contains a colon (:), which messes up Apex's built in colon structure by cutting off anything in the new page's item that happens after the colon (including the colon itself) as well as messing up any fields after that. For example: #2# has a colon in it, so P27_3, 4, and 5 will not be filled with values.
I've tried manually replacing the colon with a '%3a' (the url encoding for colon), but it doesn't seem to work.
Try using UTL_URL.ESCAPE() to escape URL special characters and UTL_URL.UNESCAPE() to un-escape them back.
You can also try APEX_UTIL.URL_ENCODE() but you need to use one or the other, i.e. either UTL or APEX_UTIL.
I've written a more detailed post about this on my blog at:
http://idisposable.co.uk/2010/07/chrome-are-you-sanitising-my-inputs-without-my-permission/
but basically, I have a string which is:
||abcdefg
hijklmn
opqrstu
vwxyz
||
the pipes I've added to give an indiciation of where the string starts and ends, in particular note the final carriage return on the last line.
I need to put this into a hidden form variable to post off to a supplier.
In basically, any browser except chrome, I get the following:
<input type="hidden" id="pareqMsg" value="abcdefg
hijklmn
opqrstu
vwxyz
" />
but in chrome, it seems to apply a .Trim() or something else that gives me:
<input type="hidden" id="pareqMsg" value="abcdefg
hijklmn
opqrstu
vwxyz" />
Notice it's cut off the last carriage return. These carriage returns (when Encoded) come up as %0A if that helps.
Basically, in any browser except chrome, the whole thing just works and I get the desired response from the third party. In Chrome, I get an 'invalid pareq' message (which suggests to me that those last carriage returns are important to the supplier).
Chrome version is 5.0.375.99
Am I going mad, or is this a bug?
Cheers,
Terry
You can't rely on form submission to preserve the exact character data you include in the value of a hidden field. I've had issues in the past with Firefox converting CRLF (\r\n) sequences into bare LFs, and your experience shows that Chrome's behaviour is similarly confusing.
And it turns out, it's not really a bug.
Remember that what you're supplying here is an HTML attribute value - strictly, the HTML 4 DTD defines the value attribute of the <input> element as of type CDATA. The HTML spec has this to say about CDATA attribute values:
User agents should interpret attribute values as follows:
Replace character entities with characters,
Ignore line feeds,
Replace each carriage return or tab with a single space.
User agents may ignore leading and trailing white space in CDATA attribute values (e.g., " myval " may be interpreted as "myval"). Authors should not declare attribute values with leading or trailing white space.
So whitespace within the attribute value is subject to a number of user agent transformations - conforming browsers should apparently be discarding all your linefeeds, not only the trailing one - so Chrome's behaviour is indeed buggy, but in the opposite direction to the one you want.
However, note that the browser is also expected to replace character entities with characters - which suggests you ought to be able to encode your CRs and LFs as
and
, and even spaces as , eliminating any actual whitespace characters from your value field altogether.
However, browser compliance with these SGML parsing rules is, as you've found, patchy, so your mileage may certainly vary.
Confirmed it here. It trims trailing CRLFs, they don't get parsed into the browser's DOM (I assume for all HTML attributes).
If you append CRLF with script, e.g.
var pareqMsg = document.forms[0]['pareqMsg']
if (/\r\n$/.test(pareqMsg.value) == false)
pareqMsg.value += '\r\n';
...they do get maintained and POSTed back to the server. Although the hidden <textarea> idea suggested by Gaby might be easier!
Normally in an input box you cannot enter (by keyboard) a newline.. so perhaps chrome enforces this even for embedded, through the attributes, values ..
try using a textarea (with display:none)..