I have searched for an answer here but have not been able to find one that meets my precise criteria.
I would like to redirect the following url:
http://site.com/term1/9/title
to
http://site.com/term1/title
There are two additional considerations:
The "term1" above could be any word; and
The number "9" above could be any number from 1 through 100.
I would be grateful for any assistance with this.
Many thanks in advance, david
Apache RewriteRule directives use perl compatible regular expressions. This should work:
RewriteRule ^([\w\d]+)/(\d+)/(.*) $1/$3
I tested it on an htaccess tester and I got the correct result. Of course, you may need to adjust the regular expression if you expect any other characters in the first part of the address. If you really need to catch the 1-100 range, you can use a more complex regular expression instead of just \d+, in the second parentheses: [0-9]{1,2}|100.
Related
I'm currently working on a Perl script and I use the CPAN module WWW:Mechanize to get HTML pages from websites.
However, I would like to be able to work on offline HTML files as well (that I would save myself beforehand most likely) so I don't need the internet each time I'm trying a new script.
So basically my question is how can I transform this :
$mech->get( 'http://www.websiteadress.html' );
into this :
$mech->get( 'C:\User\myfile.html' );
I've seen that file:// could be useful but I obviously don't know how to use it as I get errors every time.
The get() method from WWW::Mechanize takes a URL as its argument. So you just need to work out what the correct URL is for your local file. You're on the right lines with the "file://" scheme.
I think you will need:
$mech->get( 'file:///C:/User/myfile.html' );
Note two important things that people often get wrong.
URLs only understand forward slashes (/), so you need to convert Windows' warped backslash (\) monstrosities. Update: As Borodin points out in a comment, this isn't true - you can use backslashes in URLs. However, backslashes often have special meanings in Perl strings, so I'd advise using forward slashes whenever possible.
The scheme is file, which is followed by :// (with two slashes), then the hostname (which is an empty string) a slash (/) and then your local path (C:/). So that means that there are three slashes after file:. That seems wrong, so people often omit one of them. Update: description made more accurate following advice from Borodin in a comment.
Wikipedia (as always) has a lot more information - file URI scheme
According to http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL
queries can use regular expressions on both the values and the keys. While I have no trouble using regex on the values, I'm having a problem with the keys.
The example on the wiki referenced above says (among other examples):
/* finds addr:* tags with value exactly "Foo" */
node[~"^addr:.*$"~"^Foo$"];
So, that's an example of using regex on the keys and the values.
What I am interested in is the name key. Specifically the name:en key. There are a couple problems with searching by name. Not all names are in English, and for those nodes/way/relations whose names are not in English, there is no guarantee there will be a name:en tag with an English version of the name.
In general, there is no way to know in advance if the name will be in English or that there is a name:en tag. If you only ask for name or name:en, you run the risk of finding no hit. (Of course, searching for both is no guarantee of success, either.)
I have a case where I know name fails, but name:en succeeds. That is my test case. I can query the overpass-api.de/api/interpreter using this:
[out:json][timeout:25][bbox:33.465530,36.156006,33.608615,36.574516];
(
node[name~"duma",i][place];
way[name~"duma",i][place];
>;
relation[name~"duma",i][place];
node["name:en"~"duma",i][place];
way["name:en"~"duma",i][place];
>;relation["name:en"~"duma",i][place];
);
out center;
see it on overpass
and it works fine ("duma" is not found through name, but it is found with name:en), but I find it lengthy and somewhat repetitive.
I would like to use a regular expression involving the name and name:en tags, but either the server does not understand the query or I simply am using an incorrect regex.
Using the example shown in the wiki: node[~"^addr:.*$"~"^Foo$"]
I have tried:
[~"name|name:en"~"duma",i]
[~"name.*"~"duma",i]
[~"^name.*$"~"duma",i]
and several others. I even mimicked the example with [~"^name:.*"~"duma",i] just to see if anything would be returned.
Does overpass-api.de recognize regular expressions on the keys or do I just have the regex wrong? I don't get an error from overpass-api.de, just the coordinates of the bbox and an empty result. It's usually very strict about reacting to a poortly formatted query. Thanks in advance.
That's really a bug in the Overpass API implementation concerning case-insensitive key regex matching, see this Github ticket for details.
For the time being, you can already test the patch on the development box:
http://overpass-turbo.eu/s/b1l
BTW: If you don't need case-insensitive regexp matching, this should already work on overpass-api.de as of today.
I have an infected website, and I am trying to clean it out using sed. Unfortunately I am unable to escape the question mark sign in the URL and I am really stuck here. I've searched over the web for a possible solution, but unfortunately I didn't found a proper way to do so.
Just an explanation:
The injected code is similar to this one:
< iframe src=http://test.com/index.html?i=23123>< /iframe>
Note that I am not a pro, and there is why I need your help!
so my way to clear the code is :
sed -i '/< iframe src=http:\/\/test.com\/index.html\?i=23123>/,/< \/iframe>/d' index.html
Unfortunately that didn't help as well as all others.
All help will be gratefully appreciated.
echo "< iframe src=http://test.com/index.html?i=23123>< /iframe>" \
| sed 's#< iframe src=http://test.com/index.html?i=23123>< /iframe>##'
Produces no output, which to me means this is successfully deleting your problem string.
Note that most seds will accept an alternate regex-replacement character, here I am using # because there are no #s in the search target. On some seds, you have to tell it 'hey I'm using an alternate, and escape the char, like s\#.....##.
I don't see why your attempt to quote the ? is failing. Did you try [?] and (worst case) [\?]. Are there 2nd level evaluations happening by the shell that you're not mentioning here? Does my simple example also fail?
As others will certainly tell you, your approach is strictly a bandaid, you need to figure out what the security hole is in your system and fix it. Your pages will get corrupted again. :-(
IHTH
I am using PCRE|^/foo/(.*?)(?::(?:bar)?)?$| or |^/foo/(.*?)(?::bar)?:?$| this will be a replace so we want to strip : and :bar from the end while doing the replacement. I know the two are not exactly the same but it does not matter much here.
I would use the first one as it only has to check for : once. The second one could match the first three characters of :bat before having to backtrack, then check for : again. Also, the second one could match :bar: whereas the first one can't. The actual speed difference would be tiny. The second way would be better written as /^\/foo\/(.*?)(?::bar|:)?$/
Try not to use regex metacharacters as delimiters!
I read somewhere that it wasn't possible to specify multiple ports to
exclude for shellcode is that correct? if not is the following
correct?
List of ports you want to look for SHELLCODE on.
portvar SHELLCODE_PORTS ![21,25,80,143,587,8889]
I'm using snort 2905
Try it. If Snort doesn't like the syntax, it should throwback a fatal parsing error. I believe, though, that syntax is better implemented as:
portvar SHELLCODE_PORTS [21,25,80,143,587,8889]
I.e., without the negation, and then used in a rule thus:
alert tcp any any <> any !SHELLCODE_PORTS ( ... )
You could also do:
portvar SHELLCODE_PORTS [!21,!25,!80,!143,!587,!8889]
Which should be valid syntax. Haven't tested, though. YMMV.
You want !$SHELLCODE_PORTS
You are missing the dollar sign.