PHPStorm allows you access to the includes section via the #parse directive. If you're want To have Custom variables to be filled in correctly via prompt, you will need to have the variable declared in the template.
Example
"chance license.php"
/**
* @package ${Package}
* @author Chance Garcia
* @copyright (C)Copyright ${YEAR} chancegarcia.com
*/
In the above includes example, I'm wanting to have a custom variable named Package. I can only cause PHPStorm to prompt for this value if I include the variable in my template. If I'm already using the variable in the template, then it will fill in when the includes file is parsed.
Example:
<?php #parse("chance license.php") class ${Package}_#if(${ExtraClassInfo} != "")${ExtraClassInfo}_#end${NAME} { }
In the above template, the ${Package} variable will be given a prompt since it is used in the template and an unknown variable and the parsed "chance license.php" include will be able to use that prompt value.
I am also using another variable to Prompt for extra class name information. Since PHPStorm uses Velocity Template Language (VTL), I am able to use the VTL conditional syntax to insert that information if it is entered and ignore it if it is not. This technique is useful in a situation where you want your include file to have a custom variable value but do not need to display this value in your template.
Example:
<?xml version="1.0"?> <!-- #if(${Package})#end #parse("chance license.php") -->
In the above example, we make PHPStorm prompt for the custom value needed for out parsed include file. This gives us our expected include file without printing our custom variable anywhere else in our template.
So what does that actually mean when it comes to vector creation? Here is an example enumeration vector:
<*datahtmlelements* *datahtmlattributes*="javascript:parent.customLog('*datahtmlelements* *datahtmlattributes*')"></*datahtmlelements*>
*datahtmlelements* refers to a dataset and in this instance we are talking about html elements, so the placeholder will be replaced by “br”, “b”, “html” and so on, the same this will happen to *datahtmlattributes* but this time using each attribute. Shazzer checks your vector for how many instances of placeholders you have and then automatically creates a loop within all the data so it enumerates each dataset within a nested loop of up to 5 separate datasets. The amount of data is split between a maximum of 10,000 iterations so your data will all be enumerated no matter how big the total iterations are it will just take a long time for a lot of nested datasets
You can see in the vector that the placeholders are used more than once this enables you to log any interesting results, so here we use the customLog function in Shazzer to send the html element and attribute that executes. Other logging functions are available and are listed in the preparation code when you create a vector.
1. Check datasets for which data you would like to enumerate. You can create your own dataset if the one you require doesn’t exist.
2. Click create and select “Data enumeration” from the vector type drop down.
3. Give it a nice descriptive name and some keywords to find the vector.
4. You don’t actually need to modify the preparation code unless you need to log something that doesn’t execute like CSS values for instance.
5. Construct your vector by clicking and data placeholders at the bottom and craft you code as if you’re in a loop of all the data structures you use.
6. Once your vector is complete you can now fuzz the vector by choosing it from the “Fuzz vectors” list. Once you’ve found your vector you can select a doctype then click “Fuzz all” to begin fuzzing.
In future you will be able to share these enumeration vectors between your twitter followers in order to distribute the workload between friends to help scan large datasets. Happy fuzzing!
]]>I've decided to treat this effort just like I treat exercise, which is to focus on rhythm and consistency above all else. Don't break the chain. My days are packed, but I'm setting aside at least half an hour each day to do something related to learning JavaScript. As long as I hold myself to that and continue making progress, I'll be happy.
Why am I telling you this? One reason is to put myself on the hook, and another reason is so that I can share what I'm doing to learn JavaScript, in case you want to join me. (This also means those of you who have already been down this path can offer your sage advice.)
Since I've just started, I'm currently only using two sources:
I also have a copy of JavaScript: The Good Parts that O'Reilly sent me back when they wanted Sean and I to write a similar book for PHP. I'm not sure if it's best used as a guide or a reference, though.
If you're a developer and don't already consider yourself a JavaScript expert, won't you join me?
]]>Got a question? Ask me. I’ll add additional entries here as things come up.
No. I think sometimes they’re very appropriate. It depends on your needs: will the pros you get with library/component/framework X outweigh the negatives? If so, it’s probably a good choice. If not, it’s probably not.
Sometimes you do. My experience at FictiveKin has been that our small team is able to work faster, smarter, and more efficiently by minimizing the size of our PHP codebase and removing all unnecessary layers of abstraction. In some cases that meant not doing certain tasks in PHP anymore (almost all html generation was moved to the browser). In others, it meant ripping out a bunch of code and replacing it with a simpler solution that required far less boilerplate and replication. We still kept some code that had more dependencies than we’d like because the wins we get with it outweigh the downsides.
I’ve certainly seen situations where choosing a popular full-stack framework is a better idea. As teams get larger, enforcement of coding standards and not doing Dumb Shit becomes harder. Hiring and training engineers is usually easier with popular, full-stack frameworks. On the other hand, we’ve found that devs coming from non-PHP backgrounds liked how quickly they can be productive with simpler libraries and frameworks. Your mileage may vary.
Good God no. There is lots of very good, well-written code out there that’s already solved the problem you’re facing. Most of the time I don’t want to try to solve an issue like oAuth request signing, because it makes my brain hurt and I’d rather focus on building stuff. So, I’ll look for an existing solution that fits my needs first. I sometimes choose to write something from scratch because the existing solutions (that I can find – discovery is a whole other issue) don’t fit well with my existing application structure, or I feel it will introduce more maintenance issues than I’m comfortable with.
Sure. Generally I think people should work on writing libraries/components, personally. We have plenty of framework choices. But this is PHP, so you have to write your own framework sometime.
Long answer: I tend to believe that the reference implementation of “microframework” is Sinatra. Routing, request/response objects, sessions, maybe some hooks for template rendering. Generally I think the inclusion of an ORM is a clear sign of non-micro-ness.
Short answer: I don’t care, really – and you shouldn’t either. If it works for you, awesome.
Generally I think about these things:
None of these are hard and fast rules, though. I encourage people to share things with me they think others would find useful.
I don’t. I like some of their songs, but don’t own any of their work. I also think they’re incredibly smart, talented musicians. My point was to suggest there are other valid approaches, not to reject complexity outright.
]]>An early draft was already adopted by Firefox 4, and I just found out that it's also working in Chrome, Safari and IE 10.
IE10 and FF are using the following header:
X-Content-Security-Policy: default-src 'self'
While Safari and Chrome use:
X-Webkit-CSP: default-src 'self'
When the specification is finalized, the X- will be dropped, and it will simply be 'Content-Security-Policy'.
Hi Developers! Start implementing this feature! It's important for the future and security of the web. The web's biggest vulnerability, from what I understand, is still XSS, but if people start to properly implement CSP, XSS can effectively be a thing from the past.
So even if you don't want to risk using CSP on a production environment, at least consider adding the headers in your development environment. It will force you to write better code, by not embedding javascript directly into the html source. By considering this right now, you will also make it much easier if you do decide to adopt CSP at some point in the future.
I'm implementing CSP full-on in a new project, and one of the things I've noticed already is that some of the javascript we embed from 3rd parties use eval() and inline html events (onclick & friends). For the sake of security we will most likely decide to only use 3rd party code if they are indeed CSP-compatible.
]]>An early draft was already adopted by Firefox 4, and I just found out that it's also working in Chrome, Safari and IE 10.
IE10 and FF are using the following header:
X-Content-Security-Policy: default-src 'self'
While Safari and Chrome use:
X-Webkit-CSP: default-src 'self'
When the specification is finalized, the X- will be dropped, and it will simply be 'Content-Security-Policy'.
Hi Developers! Start implementing this feature! It's important for the future and security of the web. The web's biggest vulnerability, from what I understand, is still XSS, but if people start to properly implement CSP, XSS can effectively be a thing from the past.
So even if you don't want to risk using CSP on a production environment, at least consider adding the headers in your development environment. It will force you to write better code, by not embedding javascript directly into the html source. By considering this right now, you will also make it much easier if you do decide to adopt CSP at some point in the future.
I'm implementing CSP full-on in a new project, and one of the things I've noticed already is that some of the javascript we embed from 3rd parties use eval() and inline html events (onclick & friends). For the sake of security we will most likely decide to only use 3rd party code if they are indeed CSP-compatible.
]]>An early draft was already adopted by Firefox 4, and I just found out that it's also working in Chrome, Safari and IE 10.
IE10 and FF are using the following header:
X-Content-Security-Policy: default-src 'self'
While Safari and Chrome use:
X-Webkit-CSP: default-src 'self'
When the specification is finalized, the X- will be dropped, and it will simply be 'Content-Security-Policy'.
Hi Developers! Start implementing this feature! It's important for the future and security of the web. The web's biggest vulnerability, from what I understand, is still XSS, but if people start to properly implement CSP, XSS can effectively be a thing from the past.
So even if you don't want to risk using CSP on a production environment, at least consider adding the headers in your development environment. It will force you to write better code, by not embedding javascript directly into the html source. By considering this right now, you will also make it much easier if you do decide to adopt CSP at some point in the future.
I'm implementing CSP full-on in a new project, and one of the things I've noticed already is that some of the javascript we embed from 3rd parties use eval() and inline html events (onclick & friends). For the sake of security we will most likely decide to only use 3rd party code if they are indeed CSP-compatible.
]]>I’ve been a long-time user of Terminal.app, but I had been hearing good things about iTerm2. I actually used iTerm (version 1) years ago, but I switched back to Terminal.app for reasons I cannot recall. Nevertheless, iTerm2 has come a long way, and I wanted to take advantage of some of its functionality like split panes, better full-screen support, etc. So, that was the first major change I made to my tools.
Bash has been my favored shell since I began using Linux about fourteen years ago. I’d never given much thought to using a different shell, and to be honest, switching shells always seemed a daunting task. I thought I’d have to relearn my way around the shell, and everything I took for granted with Bash would be non-existent in a different shell. Fortunately, this is not true. As it turns out, zsh “can be thought of as an extended Bourne shell with a large number of improvements, including some features of bash, ksh, and tcsh” (Wikipedia).
I was able to switch to zsh without ditching my knowledge of bash. As a result, I’ve gained all the advantages of zsh, which include advanced customization and scripting capabilities, while continuing to provide most (if not all) the same functionality and commands I’m used to in bash. I have much more to learn, though, so if you have tips and tricks, please share.
If you’re interested in switching to zsh, I recommend checking out oh-my-zsh. It’s a framework for managing your zsh configuration, and it contains lots of goodies. In addition, there are great posts by Mark Nichols and Jon Kinney that will get you quickly up-to-speed with oh-my-zsh. The latter post has the awesome title “It’s not enough to bash in heads, you’ve got to bash in minds…with ZSH”.
Generally, I’ve really only used screen when I started noticing that my connection to a remote development machine was getting sluggish or I wanted to keep a constant connection to IRC, but tmux has opened my eyes to so many more possibilities that a multiplexer can offer. I’ve just only started using it, so I can’t say much about it, but I encourage you to read Hawk Host’s two-part post on tmux.
I used irssi in a screen session for years. Then, I decided I needed Growl notifications from my IRC client. I quit using irssi in favor of Linkinus. I’ve used Linkinus for about two years—together with the IRC bouncer znc for some of that time—but I’ve continued to miss the flexibility and functionality of irssi. On a whim, I decided to switch back to irssi, but it wasn’t without so
Truncated by Planet PHP, read more at the original (another 3132 bytes)
]]>