Is there a way to use an extra parameter to avoid the length (l=) tag in the DKIM-signature ?
Also I am looking for a way to change the alignment mode from "relaxed/simple" into "relaxed/relaxed", but I cannot find a way.
As I understood, it is recommended NOT to use l= (especially if you have troubles reaching hotmail-addresses) and use "relaxed/relaxed"
I am using phpmailer 5.2.7
Looking forward to your answer
Related
I'm currently learning webfocus and I'm learning about defining, but what is teaching me isn't doing a great job. An example that has been given to me is about cars. If I want to make a new field to find the difference between the retail cost and the dealer cost, they said to input
DEFINE FILE CAR
CALCULATED_DIFFERENCE/D5 = RETAIL_COST - DEALER_COST
END
What I'm confused about is what the
/D5
is there for. Is it required to define a file? Does it have to be something specific? I've researched a lot but haven't found any answers about it.
From what I understand, it joins the aliases and roots. For example the D could be short for difference. The 5 could just be a number. Without all of the example and question it's hard to say.
Here is another example http://www.hwconline.com/ibi_html/javaassist/intl/EN/help/source/topic547.htm
Section
A preceding forward slash '/' is required for all aliases and context roots. The WebFOCUS Administration Console automatically adds a forward slash if one was not entered.
I am assuming it could be a pointer. Look at the url and the / indicates like a tree node. If you want to get to a location then it's location/location/location/here
here being what your looking at. So if the /D5 is called it could mean page/page/page/Difference5 so for short it omits all of the pages and signifies the direct alias D5.
I am not entirely sure but that is what I have always thought. Look at everything dealing with locations a \ or / is always used.
I've found out what it means. The /D5 is known as formatting. It allows WebFOCUS to know what is being used in the file. The D stands for decimal, which means that if I wanted to I could format it as D/5.2 and an A stands for alphanumeric. If I were to define a file called person_last_name, I would use A/30. The number determines how much data it can hold, so 30 is all I need as a person's last name probably won't be longer than 30 characters.
Vimperator uses strictly numeric hints by default. This has several disadvantages:
Smaller scope: it only takes 10 links to get to double digits
Number keys are harder to type
Is there any way to make Vimperator use more characters (ideally [a-zA-Z0-9])?
There is an option called hintchars, that changes the characters that are used for hints.
You have put the following line in your .vimperatorrc, of course with exactly the characters on the right hand side that you want to use:
set hintchars=asdfghklqwertyuiop
To add to answer above. If you type set hintchars= you'll get a nice list of recommendations
You can set the values to pretty much any keys though just remember that the order matters and the hints will start in that order so Smart Order is pretty awesome.
If you prefer more characters you can make it case sensitive by setting it to:
hjklHJKL... so first 8 links will always be at your fingertips !
We have performance issue using for controls which gets number in the format of $dollars as input. In-order to over come this performance issue we used instead of and implemented the following calculate functionality in the bind of the control.
<xforms:bind id="Amount"
nodeset="instance('sample_form')/Amounts/Amount"
calculate="if (. !=0)
then format-number(xs:double(.),'$#,##0.000')
else ."/>
But the problem with the above code is, its converting the control's value into String type which leads to error in the controls which has its value dependent on this. Kindly provide me a solution for the above problem or provide a better recommendation to handle this situation.
If you only want to show the formatted value (which I assume to be the case since you are thinking of using a calculate), then you could put that expression you have on the calculate inside an:
<xforms:output value="..."/>
If you need both input and output, and you'd like the value stored in your instance to be just the unformatted number, then I don't think there is an easy way around using <fr:currency> other than somehow reimplementing the functionality provided by <fr:currency>. If you need both input and output, then I would recommend you to investigate this further to find, and then solve, the source of the performance issue.
Am wondering if the combination of trim(), strip_tags() and addslashes() is enough to filter values of variables from $_GET and $_POST
That depends what kind of validation you are wanting to perform.
Here are some basic examples:
If the data is going to be used in MySQL queries make sure to use mysql_real_escape_query() on the data instead of addslashes().
If it contains file paths be sure to remove the "../" parts and block access to sensitive filename.
If you are going to display the data on a web page, make sure to use htmlspecialchars() on it.
But the most important validation is only accepting the values you are expecting, in other words: only allow numeric values when you are expecting numbers, etc.
Short answer: no.
Long answer: it depends.
Basically you can't say that a certain amount of filtering is or isn't sufficient without considering what you want to do with it. For example, the above will allow through "javascript:dostuff();", which might be OK or it might not if you happen to use one of those GET or POST values in the href attribute of a link.
Likewise you might have a rich text area where users can edit so stripping tags out of that doesn't exactly make sense.
I guess what I'm trying to say is that there is simple set of steps to sanitizing your data such that you can cross it off and say "done". You always have to consider what that data is doing.
It highly depends where you are going to use it for.
If you are going to display things as HTML, make absolutely sure you are properly specifying the encoding (e.g.: UTF-8). As long as you strip all tags, you should be fine.
For use in SQL queries, addslashes is not enough! If you use the mysqli library for example, you want to look at mysql::real_escape_string. For other DB libraries, use the designated escape function!
If you are going to use the string in javascript, addslashes will not be enough.
If you are paranoid about browser bugs, check out the OWASP Reform library
If you use the data in another context than HTML, other escaping techniques apply.
I'm trying to handle this possible exploit and wondering what is the best way to do it? should i use apache's common-validator and create a list of known allowed symbols and use that?
From the wikipedia article:
The generic solution is to URL-encode strings before inclusion into HTTP headers such as Location or Set-Cookie.
Typical examples of sanitization include casting to integer, or aggressive regular expression replacement. It is worth noting that although this is not a PHP specific problem, the PHP interpreter contains protection against this attack since version 4.4.2 and 5.1.2.
Edit
im tied into using jsp's with java actions!
There don't appear to be any JSP-based protections for this attack vector - many descriptions on the web assume asp or php, but this link describes a fairly platform-neutral way to approach the problem (jsp used as an incidental example in it).
Basically your first step is to indentify the potentially hazardous characters (CRs, LFs, etc) and then to remove them. I'm afraid this about as robust a solution as you can hope for!
Solution
Validate input. Remove CRs and LFs (and all other hazardous characters) before embedding data into any HTTP response headers, particularly when setting cookies and redirecting. It is possible to use third party products to defend against CR/LF injection, and to test for existence of such security holes before application deployment.
Use PHP? ;)
According to Wikipedia and the PHP CHANGELOG, PHP's had protection against it in PHP4 since 4.4.2 and PHP5 since 5.1.2.
Only skimmed it -- but, this might help. His examples are written in JSP.
ok, well casting to an int is not much use when reading strings, also using regex in every action which recieves input from browser could be messy, im looking for a more robust solution