in some CakePHP apps you can find
preg_replace('/["\']/', '”', addslashes(strip_tags($thisHere)))
like in http://noserub.googlecode.com/svn/branches/development/app/app_controller.php
where $this->Controller->here is "additionally secured" in some way
a) what exactly is/was the problem with it? could it hurt the application? I cannot imagine that " or ' could harm it in any way.
b) is it still useful? or are all "possible dangers" already fixed in the more current cake versions?
if so: are there any use case scenarios where one could actually test the possible issues?
NOTE: in 2.0 it has moved to "$this->request->here" - but still contains the current absolute url (/controller/action/..).
I think the comment above the line in question is pretty clear:
/**
* Don't you EVER remove this line else you will make the whole
* application a swiss cheese for XSS!
* We often call echo $this->here in our form actions and this would
* be exactly where the injection would take place.
*/
$this->here = preg_replace('/("|\')/', 'â€', addslashes(strip_tags($this->here)));
it seems that the method is totally unnecessary as the form helper should escape automatically.
and for all other use cases you should just escape the url.
citing
http://groups.google.com/group/cake-php/browse_thread/thread/39e1024efe918e66/efb8ee0bea7bcd1
Related
Essentially trying to test the result of a function that contains 3 irrelevant string properties (irrelevant to this question). But a 4th property that is a ISO 8601 string that gets created when the function gets executed. I have no way of knowing what this exact value will be, so I want to test the property via regex. Usually I'd do something like this (which would work but not as clean):
expect(desiredProperty).toMatch(ISOPattern); // ISOPattern = regex i made that works
But doing it this way would mean i need to write this expect for every single property, whereas something like this is more clean and easier to read:
expect(result).toEqual(
expect.objectContaining({
id: mockEmail,
otpPassword: mockOtpPassword,
expire: 1000 * 60 * 60,
expire_at: expect.toMatch(ISOPattern), // NOT WORKING, FAILS
})
);
So I am wondering, is doing something like the above possible at all? I could just not check that property in my expect.objectContaining function, and add another expect to do what i mentioned above. But again, wondering if I could have the best of both worlds.
Not sure if I formatted my post right but essentially this is what I ended up doing (i mentioned this in the OP):
expect(result).toEqual(
expect.objectContaining({
id: mockEmail,
otpPassword: mockOtpPassword,
expire: 1000 * 60 * 60
})
);
expect(result.expire_at).toMatch(ISOPattern);
So the idea here was to get rid of the extra expect call (if you notice here I am checking against the same object result, but I wont know the value of the date and its not important anyways so I just want to check some regex I wrote (whether this works or not is irrelevant although the regex works for sure), and somehow do the regex check inside the expect.objectContaining function, but I dont think I did a good job at formatting my question right so thats probably on me.
Open to anyones help if they see a way to do what im talking about.
The code in this solution is what I am using now, the question I am trying to ask is if theres a better way to do this. The regex working is not relevant, although I know 100% it does work. I did not provide this regex because its literally not what I am asking or relevant to the solution I am seeking.
why not 1 line 1 var:
var Class = new(require(‘./class.js’))();
instead common way of 2 lines and 2 vars:
var Class = require(‘./class.js’);
var object = new Class();
I see numerous issues with this approach.
If you move the code between files, you have to update the path in every object instantiation.
If you move the file, you have to update much more requires.
This makes your code less portable - if you will ever use it on client, with different approach for including scripts, you will have to change your code.
You just need to type more to instantiate a class.
This is not how most (probably 99.9%) of the other people do it.
It postpones the "missing module" error to the latter time - this is quite dangerous.
This is probably not in line with future ES6 modular approach.
Well, maybe too personal, but I just do not like it.
Can't stop adding points to this list. Help me! Aaaaa!
Well. Now it is under control. Actually, nice trick. I will use it but not for anything bigger than one line. :)
Consider the following sample codes:
1.Sample
var IsAdminUser = (User.Privileges == AdminPrivileges)
? 'yes'
: 'no';
console.log(IsAdminUser);
2.Sample
var IsAdminUser = (User.Privileges == AdminPrivileges)?'yes': 'no';
console.log(IsAdminUser);
The 2nd sample I am very comfortable with & I code in that style, but it was told that its wrong way of doing without any supportive reasons.
Why is it recommended not to use a single line ternary operator in Node.js?
Can anyone put some light on the reason why it is so?
Advance Thanks for great help.
With all coding standards, they are generally for readability and maintainability. My guess is the author finds it more readable on separate lines. The compiler / interpreter for your language will handle it all the same. As long as you / your project have a set standard and stick to it, you'll be fine. I recommend that the standards be worked on or at least reviewed by everyone on the project before casting them in stone. I think that if you're breaking it up on separate lines like that, you may as well define an if/else conditional block and use that.
Be wary of coding standards rules that do not have a justification.
Personally, I do not like the ternary operator as it feels unnatural to me and I always have to read the line a few times to understand what it's doing. I find separate if/else blocks easier for me to read. Personal preference of course.
It is in fact wrong to put the ? on a new line; even though it doesn’t hurt in practice.
The reason is a JS feature called “Automatic Semicolon Insertion”. When a var statement ends with a newline (without a trailing comma, which would indicate that more declarations are to follow), your JS interpreter should automatically insert a semicolon.
This semicolon would have the effect that IsAdminUser is assigned a boolean value (namely the result of User.Privileges == AdminPrivileges). After that, a new (invalid) expression would start with the question mark of what you think is a ternary operator.
As mentioned, most JS interpreters are smart enough to recognize that you have a newline where you shouldn’t have one, and implicitely fix your ternary operator. And, when minifying your script, the newline is removed anyway.
So, no problem in practice, but you’re relying on an implicit fix of common JS engines. It’s better to write the ternary operator like this:
var foo = bar ? "yes" : "no";
Or, for larger expressions:
var foo = bar ?
"The operation was successful" : "The operation has failed.";
Or even:
var foo = bar ?
"Congratulations, the operation was a total success!" :
"Oh, no! The operation has horribly failed!";
I completely disagree with the person who made this recommendation. The ternary operator is a standard feature of all 'C' style languages (C,C++,Java,C#,Javascript etc.), and most developers who code in these languages are completely comfortable with the single line version.
The first version just looks weird to me. If I was maintaining code and saw this, I would correct it back to a single line.
If you want verbose, use if-else. If you want neat and compact use a ternary.
My guess is the person who made this recommendation simply wasn't very familiar with the operator, so found it confusing.
Because it's easier on the eye and easier to read. It's much easier to see what your first snippet is doing at a glance - I don't even have to read to the end of a line. I can simply look at one spot and immediately know what values IsAdminUser will have for what conditions. Much the same reason as why you wouldn't write an entire if/else block on one line.
Remember that these are style conventions and are not necessarily backed up by objective (or technical) reasoning.
The reason for having ? and : on separate lines is so that it's easier to figure out what changed if your source control has a line-by-line comparison.
If you've just changed the stuff between the ? and : and everything is on a single line, the entire line can be marked as changed (based on your comparison tool).
This is PascalCase: SomeSymbol
This is camelCase: someSymbol
This is snake_case: some_symbol
So my questions is whether there is a widely accepted name for this: some-symbol? It's commonly used in url's.
There isn't really a standard name for this case convention, and there is disagreement over what it should be called.
That said, as of 2019, there is a strong case to be made that kebab-case is winning:
https://trends.google.com/trends/explore?date=all&q=kebab-case,spinal-case,lisp-case,dash-case,caterpillar-case
spinal-case is a distant second, and no other terms have any traction at all.
Additionally, kebab-case has entered the lexicon of several javascript code libraries, e.g.:
https://lodash.com/docs/#kebabCase
https://www.npmjs.com/package/kebab-case
https://v2.vuejs.org/v2/guide/components-props.html#Prop-Casing-camelCase-vs-kebab-case
However, there are still other terms that people use. Lisp has used this convention for decades as described in this Wikipedia entry, so some people have described it as lisp-case. Some other forms I've seen include caterpillar-case, dash-case, and hyphen-case, but none of these is standard.
So the answer to your question is: No, there isn't a single widely-accepted name for this case convention analogous to snake_case or camelCase, which are widely-accepted.
It's referred to as kebab-case. See lodash docs.
It's also sometimes known as caterpillar-case
This is the most famous case and It has many names
kebab-case: It's the name most adopted by official software
caterpillar-case
dash-case
hyphen-case or hyphenated-case
lisp-case
spinal-case
css-case
slug-case
friendly-url-case
As the character (-) is referred to as "hyphen" or "dash", it seems more natural to name this "dash-case", or "hyphen-case" (less frequently used).
As mentioned in Wikipedia, "kebab-case" is also used. Apparently (see answer) this is because the character would look like a skewer... It needs some imagination though.
Used in lodash lib for example.
Recently, "dash-case" was used by
Angular (https://angular.io/guide/glossary#case-types)
NPM modules
https://www.npmjs.com/package/case-dash (removed ?)
https://www.npmjs.com/package/dasherize
Adding the correct link here Kebab Case
which is All lowercase with - separating words.
I've always called it, and heard it be called, 'dashcase.'
There is no standardized name.
Libraries like jquery and lodash refer it as kebab-case. So does Vuejs javascript framework. However, I am not sure whether it's safe to declare that it's referred as kebab-case in javascript world.
I've always known it as kebab-case.
On a funny note, I've heard people call it a SCREAM-KEBAB when all the letters are capitalized.
Kebab Case Warning
I've always liked kebab-case as it seems the most readable when you need whitespace. However, some programs interpret the dash as a minus sign, and it can cause problems as what you think is a name turns into a subtraction operation.
first-second // first minus second?
ten-2 // ten minus two?
Also, some frameworks parse dashes in kebab cased property. For example, GitHub Pages uses Jekyll, and Jekyll parses any dashes it finds in an md file. For example, a file named 2020-1-2-homepage.md on GitHub Pages gets put into a folder structured as \2020\1\2\homepage.html when the site is compiled.
Snake_case vs kebab-case
A safer alternative to kebab-case is snake_case, or SCREAMING_SNAKE_CASE, as underscores cause less confusion when compared to a minus sign.
I'd simply say that it was hyphenated.
Worth to mention from abolish:
https://github.com/tpope/vim-abolish/blob/master/doc/abolish.txt#L152
dash-case or kebab-case
In Salesforce, It is referred as kebab-case. See below
https://developer.salesforce.com/docs/component-library/documentation/lwc/lwc.js_props_names
Here is a more recent discombobulation. Documentation everywhere in angular JS and Pluralsight courses and books on angular, all refer to kebab-case as snake-case, not differentiating between the two.
Its too bad caterpillar-case did not stick because snake_case and caterpillar-case are easily remembered and actually look like what they represent (if you have a good imagination).
My ECMAScript proposal for String.prototype.toKebabCase.
String.prototype.toKebabCase = function () {
return this.valueOf().replace(/-/g, ' ').split('')
.reduce((str, char) => char.toUpperCase() === char ?
`${str} ${char}` :
`${str}${char}`, ''
).replace(/ * /g, ' ').trim().replace(/ /g, '-').toLowerCase();
}
This casing can also be called a "slug", and the process of turning a phrase into it "slugify".
https://hexdocs.pm/slugify/Slug.html
Within Node.js, I am using querystring.stringify() to encode an object into a query string for usage in a URL. Values that have spaces are encoded as %20.
I'm working with a particularly finicky web service that will only accept spaces encoded as +, as used to be commonly done prior to RFC3986.
Is there a way to set an option for querystring so that it encodes spaces as +?
Currently I am simply doing a .replace() to replace all instances of %20 with +, but this is a bit tedious if there is an option I can set ahead of time.
If anyone still facing this issue, "qs" npm package has feature to encode spaces as +
qs.stringify({ a: 'b c' }, { format : 'RFC1738' })
I can't think of any library doing that by default, and unfortunately, I'd say your implementation may be the more efficient way to do this, since any other option would probably either do what you're already doing, or will use slower non-compiled pure JavaScript code.
What about asking the web service provider to follow the RFC?
https://github.com/kvz/phpjs is a node.js package that provides all the php functions. The http_build_query implementation at the time of writing this only supports urlencode (the query string includes + instead of spaces), but hopefully soon will include the enc_type parameter / rawurlencode (%20's for spaces).
See http://php.net/http_build_query.
RFC1738 (+'s) will be the default enc_type either way, so you can use it immediately for your purposes.