La schedulazione di procedure ricorrenti è una cartatteristica di molte applicazioni, soprattutto quelle di una certa complessità. In questo articolo vediamo come sia semplice integrare Quartz in applicazioni esistenti e che facciano uso dello Spring framework.

UrlRewriteFilter - un mod_rewrite per le servlet

In questo articolo spiego come utilizzare UrlRewriteFilter, un utilissimo filtro che emula il comportamento di mod_rewrite, permettendo magie altrimenti molto difficili da realizzare "a mano"

Hoje vamos falar desse tema que está tão comentado no mundo web.

Atualmente tanto se fala em SEO, sistemas de busca, ranking, posicionamento em sistemas de busca, etc. Utilizar url amigáveis no seu site poderá ajudá-lo a atingir estes objetivos.

Mas e o que são urls amigáveis? Como identifico uma url amigável?

Vamos ao que interessa!

http://www.seusite.com.br/index.php?categoria=5&pg=10  -> url comum
http://www.seusite.com.br/artigos/5/10/                            -> url amigável?

Deu para perceber? É muito mais fácil para qualquer pessoa acessar a segunda opção, não acha? Pois bem, para os robôs de busca, também! Assim o conteúdo do seu site terá muito mais relevância para as palavras buscadas!

Existem algumas técnicas para obter estes resultados. Vou passar para vocês a que uso no meu dia-a-dia.

Para utlizar este método de "re-escrita da url" vamos precisar que o mod_rewrite do apache esteja ativado, para isto basta descomentar a linha abaixo no seu httpd.conf:

LoadModule rewrite_module modules/mod_rewrite.so

A técnica que vou mostrar para vocês já está bastante conhecida na internet, portanto não será difícil encontrar outros exemplos para isto.  Esta técnica utiliza o arquivo .htaccess e um arquivo php para direcionar o usuário para a página correta (não é redirecionamento).

Crie um arquivo chamado .htaccess e coloque o seguinte (explico as linhas nos comentários)

<IfModule mod_rewrite.c>
#habilita o modulo Rewrite
RewriteEngine On
#Indica qual é a pasta base do conteúdo do site
RewriteBase /
#Verifica se a url digitada é um arquivo caso seja para aqui
RewriteCond %{REQUEST_FILENAME} !-f
#Verifica se a url digitada é uma pasta caso seja para aqui
RewriteCond %{REQUEST_FILENAME} !-d
#Mostra o caminho completo do meu arquivo default.php - tratamento dos dados
RewriteRule .(/)?$ /default.php
</IfModule>

No seu arquivo default.php você deve colocar isto:

<?php
//recupera num array o conteúdo passado na url
$gets = explode("/",str_replace(strrchr($_SERVER["REQUEST_URI"], "?"), "", $_SERVER["REQUEST_URI"]));
//Elimina o 1°  ítem pois está vazio
array_shift($gets);

//Verifica se é um arquivo existente
if(file_exists($gets[0] . ".php")){
//inclui o arquivo
require ($gets[0] . ".php");

}else{
//Caso contrário envia para a página base
header("Location: /");
}
?>

Pronto, é isso aew! Agora é só testar! Utilizo isto frequentemente, e caso vocês não tenham percebido mas o próprio wordpress utiliza url amigáveis.
Vlw, até a próxima!

Bei Wikipedia sieht es doch ganz schön aus: http://de.wikipedia.org/wiki/Gürtel

Das würde bei mir rauskommen: www.domain.de/Guertel.htm

Nun ist man aber manchmal damit konfrontiert, die Url für Fremdsprachen 'schön' zu schreiben. Wie werden denn nun solche Sonderzeichen im Ausland umgeschrieben? An dieser Stelle eine kleine Sammlung:

Deutschland:

Frankreich:

Dänemark:

Ungarn:
...

Weitere Umlaute folgen, Vorschläge können einfach dazukommentiert werden.

RewriteMap Directive
(...)
Context: server config, virtual host
(...)

this directive can be set only as described, not in .htaccess file.

But really.. there's  no problem. Solution for PHP.

To replace links like:

http://www.com/index.php?fa=Shop.List&directoryId=334&subcat=f5a7&view=full
to
http://www.com/List,cable,tube,photo

A map file (should be hidden from browsers for the best) must contain some entrys ( values can be extracted from DataBase too ) i.e.:

File: rewriteMap.inc

List Shop.List
cable 349
tube f5a7
photo full

Then create an example rule:

RewriteRule ^([A-Za-z0-9_\-]+)\.htm$ /index.php?urlsel=$1 [NC,L]

[NC,L] (if needed) means no casesensitive and Last rule.
Condition ^([A-Za-z0-9_\-]+)\.htm$ specifies files with letters, numbers and - and _ and included .htm suffix. 

This rule takes us INTERNALLY to:

http://www.com/index.php?urlsel=$1

where $_GET['urlsel'] is = "List,cable,tube,photo"

Now it can be processed and served.
Yet it can better.
Why not create shortest links as possible.

Instead of multiple parameter combinations, rewriteMap.inc can hold links already prepared for single locations or ready to use parameters for each single link.

Example file: rewriteMap.inc

guitar   modelC3   param1   param2   param3   id1
guitar   modelA3   param1   param2   param3   id2
drum   modelSH   param1   praram2   param3   id3

URL entered: 

http://www.com/guitar-modelC3.htm  

Rule invisible redirects us to:

http://www.com/index.php?urlsel=$1 ( user still sees http://www.com/guitar-modelC3.htm)

Inside of index.php $_GET['urlsel'] is = "guitar-modelC3".
File index.php reads a rewriteMap.inc - or gets data from DB.
What's good that even if You don't secure this $_GET - nothing happens, cause there will be NO INDEX found, but depending of  solution You may want to secure it (I do and You can read some at my previous article  Secure PHP variables $_GET, $_POST - wrapper function).

Now data from rewriteMap.inc or database can be retrieved and put into control variables in script.
Data from rewriteMap.inc can be converted to an associative array indexed with keys as follows:

array[] of array[]
array[ guitar-modelC3 ] => array ([0] param1[1] param2 [2] param3 [3] id)

to simplify access.

Of course file rewriteMap.inc should be created dynamically by Your www/CMS engine, by hand only with small web services or in special cases.

With this solution and a hughe URL links count, You'll have to consider some efficiency optimizations. But i'm sure You know that if you reading this.

Using data base engine to store rewriteMap data depends of created data base model.

And that's it.
This is only workaround idea to .htaccess problem. Optimization, alternatives and security aspects are beside of  this blog entry.
It works for me but  I do not take responsibility of any entry on this blog. Use it all at Your own risk.

( I use comma instead of / to avoid special treatment for CSS, JS and other client side included files - we don't need that at this time )
( About mod_rewrite and URL rewriting You can read a great article here: URL rewriting )

Source: http://www.addedbytes.com/cheat-sheets/

أولا : رمضان مبارك للجميع و تقبل الله صيامنا و صالح اعمالنا باذن الله

موضوعنا لليوم هو عن

URL Rewriting

هو خاصية من الخواص التي يمكن تفعيلها عن طريق ملف htaccess

تسمح بتغيير هيئة الرابط لغرض رفع ترتيب الموقع في محركات البحث أو لمنع المتطفلين و المخترقين و لكن هل يمكن استعراض ثغرات الموقع إذا كان مفعل هذه الخاصية ؟ قبل الاجابة على هذا دعنا نتعرف على الـ URL REWRITING

مقدمة :

تخيل أن مخترق يبحث في موقع عن ثغرة لكن لسوء الحظ كل الملفات .html و كالمعروف لغة

HTML تُعرف ان ليس لها ثغرة لأنها ليست لغة ديناميكية أو تفاعلية (في الحقيقة أظن أن ليس لها أية علاقة بالبرمجة :))

هل هذا يعني أن الـ .html غير مصاب بأي ثغرة ؟

خطاأأأأأأ لأن صاحب الموقع يمكنه التلاعب برابط صفحاته كما يشاء و هذا ما يسمى الـ

URL Rewriting..

نظرة على الـ Regex :

إذا كنت تعرف الـ regex أو الـ regular expressions من قبل مع الـ php أو الـ perl فيمكنك تجاهل هذا الجزء .

بكل بساطة الـ regex هي عبارة عن نموذج يسمح بوصف سلسلة نصية .

هذه بعض القواعد الهامة في الـ regex :

1. النقطة (.) تمثل أي حرف أو رقم أو رمز .
2. النجمة (*) تعني أن الرمز الذي قبلها يتكرر "صفر أو أكثر من مرة" يعني ليس الزامي مثال "tr*.txt" تقبل "t.txt" و "tr.txt" أو "trr.txt" أو "trrr.txt" الخ....
3. الزائد (+) يعني ان الرمز الذي قبله يعاد "مرة أو أكثر أي مرة على الأقل" مثال "tr+.txt" تقبل "tr.txt" و "trr.txt" أو "trrr.txt" و لكن لا تقبل "t.txt" فحذار !
4. العارضتان [] تمثلان صفا ما فـ [a-z] تمثل الحروف من a الى z صغيرة lowercase و الكبيرة [A-Z] و الأرقام [0-9] و الجميع [a-zA-Z0-9] و مثلا [ad] هي نفسها [abcd] و [adj] تعني الأحرف التالية a,d,j
5. ^  تعني بداية السطر و $ تعني نهايته و لكن انتبه فــ /[a-z]^/ و /[a-z^]/ ليس نفس الشيء الأولى تعني أن يبدأ السطر بأحد الحروف من a الى z أما الثانية هي أن لا يبدأ السطر بأحد تلك الحروف و لهذا انتبهوا فمكان ^ له فرق
6. القوسان () يسمحان بأخذ النص الذي يقابل الـregex التي بداخلهما و النتيجة مخزنة في متغير $1 و اذا كان هنالك عدة أقواس فالمتغيرات هي $2 , $3 .....
7. الحاضنتان {} تمثلان التكرار و نستعمل الفاصلة , لتحديد البداي و النهاية فمثلا
   ".{3,7}" تمثل أي رموز من ثلاثة إلى سبعة لأننا قلنا أن النقطة تكثل أي شيء
8. الـ backslash يستعمل يستعمل لعدم تشخيص رمز ما فماذا إذا أردنا البحث عن نقطة في النص هل نكتب "." خطأ لأن هذا يمثل أي رمز و لهذا نستعمل الـ backslash و العبارة الصحيحة هي "\."

الآن بعد أن تعرفتم على قواعد الـ regex ينمكنك فهم هذه العبارة :

[a-z0-9]@[a-z0-9]\.[a-z0-9]{1,4}

طبعا ! هي عبارة عن ايميل !

و إذا احببتم الـ Regex فطبعا ستحبون البيرل فهي رائعة في التعامل معها

أساسيات URL Rewriting :

URL Rewriting مسموح في الـ Apache من الوحدة (mod_rewrite) والتي تمكننا من اعادة كتابة الرابط . تتم كل الاعدادات في ملف hatccess الموجود داخل مجلد public_html عادة أي المجلد الرئيسي للموقع .

مثال :

تشغيل الخاصية#
RewriteEngine on

الاعدادات#
RewriteRule photos-(.+)\.html     /index.php?page=photos&p=$1    [L]
RewriteRule index\.html           /index.php                     [L]
RewriteRule ([a-z]+)\.html        /index.php?page=$1             [L]

في السطر الأول شغلنا الخاصية و ألأسطر التالية قمنا بالاعدادات .

الآن سأشرح المثال الأول فقط

RewriteRule photos-(.+)\.html     /index.php?page=photos&p=$1    [L]

في الحقيقة المستخدم يدخل الى هذا الرابط index.php?page=photos&p=$1

مع العلم أن $1 هو متغير يمكن أن يكون 1 أو 55 أو album أو أي شيء ثم سيتم التحويل الى

photos-(.+)\.html

نلاحظ هنا (.+) و هذا يعني أي رمز يعاد على الأقل مرة واحدة ثم الـbackslach \. و هذا لعدم تشخيص النقطة كأي رمز بل سيتم تشخيصها كنقطة .!

و كل هذه العملية ستتم في سر أي أن المستخدم لا يعلم ما يجري فهو يظن أنه يتصفح في موقع كله بالـHtml

الأخطار و الثغرات :

الكثير الكثير من الأصحاب المواقع يهملون موقعهم المصاب بعدة ثغرات و يقومون بتفعيل هذه الخاصية ظنا منهم أنها ستحميهم لكن المخترق إذا رأى مثلا news-2.html ثم news-13.html سيتفطن أن الرابط الحقيقي هو news.php?id=2 مثلا و في الحال سيقوم بالتالي news-and 1=1.html .

هذا في حال أن صاحب الموقع قد كتب في ملف htaccess

RewriteRule news-(.+)\.html           /news.php?id=$1                     [L]

لكن لو كانت هكذا :

RewriteRule news-([0-9]+)\.html           /news.php?id=$1                     [L]

فمستحيل تخطيها لأنه قام بفلترة فالمدخلات لن تكون إلا أعدادا

لكن لا مستحيل في عالم الهكر فلو أن المخترق عرف اسم الملف الحقيقي news.php و كان الملف مصاب فلا شيء يعيقه .

الخاتمة

أولا ، اعذروني اخوتي على الاطالة لأن هذا موضوع مهم و لم أرى من قبل في أي منتدى عربي قد تطرق له !!!

و ما يجب تذكره هو ان ليس URL Rewriting هو نفسه المصاب بثغرة بل أنه يخفي وراؤه ثغرات في ملفات السكريبت .

هذا و الله أعلم

لا تنسوني من صالح دعائكم

سلاآم

Você possui diversos domínios hospedados em um servidor Apache e deseja que todos eles sejam redirecionados para um outro domínio.

Solução:

Utilizar o mod_rewrite do apache com as seguintes condições e regra:

RewriteCond %{HTTP_HOST} ^dominio1.com(.*)      [OR]
RewriteCond %{HTTP_HOST} ^www.dominio1.com(.*)  [OR]
RewriteCond %{HTTP_HOST} ^outrodominio.com(.*)  [OR]
RewriteCond %{HTTP_HOST} ^paraquetantodominio.com(.*)
RewriteRule ^/(.*) http://www.dominioprincipal.com/$1   [L,R=301]

Notas:

• Os domínios dominio1.com, www.dominio1.com, outrodominio.com e paraquetantodominio.com devem estar configurados em ServerAlias
• O (.*) é uma expressão regular (ER) que funciona como um coringa: deste ponto em diante a URL pode possuir qualquer seqüência de caracteres e ainda assim a condição será válida.
• O $1 na linha RewriteRule diz ao Apache para completar o caminho do domínio.  Na verdade ele copia os caracteres que foram substituidos pela expressão regular  (.*) que está em ^/(.*) para frente do novo caminho.
• O [L,R=301] significa:
  L : Não execute outra regra, esta é a última
  R=301 : Retorne ao usuário o código de status HTTP 301 (Moved Permanently).  Outros códigos HTTP e mais informações podem ser encontrados aqui. Se você utilizar apenas R o código que será enviado será o 302 (Moved Temporarily).
• Recomendo a leitura da página da Apache sobre o mod_rewrite.

Instead of using id's in the URL we are going to use the page title. We will not include the id of the object in the URL because if we had to do that, this wouldn't make it easier to navigate through since you have to know both the id and title of the object. In this post we will take a look at how we can use a game title instead a game id in our URL. The visitors of the site can easily guess the title of the game and just type it in!

Then end result will look something like this:

http://www.dosspot.com/games/sam-and-max-hit-the-road/

Looks nice? It looks a lot better than the current URL:

http://www.dosspot.com/details.php?gameid=1

So, here is what we need: A PHP function which takes a string and turn it into friendly chars we can use in our URL, a new column in our database table and finally some new lines in our .htaccess file.

OK, so what do we do with our PHP function? We keep it simple and effective. Anything not matching a char between a-z and A-Z or a number, 0-9, will be removed from the title. Every space we find we replace with a -.

Example: Command and Conquer: Tiberan Dawn will do. This title would be suitable as a URL. We use our function and it will look like this: command-and-conquer-tiberan-dawn. Simple, nice and really cool!

The implementation of this is not that hard. We extract and remove all bad chars in the title. It's very straightforward. Five lines of code:

function createPermaLink($string)
{
$string = preg_replace("/(:|;|-|\"|\/|\(|\)|\')/", "", strtolower($string));
$string = preg_replace("/(\s)/", "-", strtolower($string));
return $string;
}

We will use this function everytime we want to link to a game page. We will send the game title as the argument into the createPermaLink function and it will return a clean and URL friendly string back to us.

Next up we go to the MySQL database table we want to match our perma link with. We add a new coloumn named perma as a varchar length 100. We take the game title and use our newly created createPermaLink function and copy the text and paste it into the new database column. So, the database table might look like this:

ID Title                                                      Perma
1    Sam and Max Hit the Road             sam-and-max-hit-the-road

Now we are able to do a SQL statement and try to select the row with a Perma value matching the incoming perma value from the URL. To be able to send a perma via the URL we need to add lines to our .htaccess file. Again, very easy:

RewriteRule ^([a-z0-9\-]+)/$ /game.php?perma=$1 [L]

Here I have a rule saying: Anything that matches a-z chars or 0-9 integers or a - is valid and it's redirected to my game.php page with a querystring attached named perma with a value. The value in our case will be the game title transformed by our createPermaLink function.

So in our game.php file we simple write a SQL statement to fetch the corrent row with our Database class:

$perma = mysql_real_escape_string($_GET['perma']);
$result = $db->fetchQuery("SELECT * FROM games WHERE perma = '$perma'");

Pretty simple huh? The first line is just making sure that no hackers can break into our database and after that we use the $db object which is an instant of our Database class and we call our fetchQuery method to retrieve the row we want.

Three different areas we need to modify but only with very little code we are able to add the page title in the URL quite simple. The URL's is a lot nicer and SEO loves it!

I also used a trick i found here to do mod_rewrite-ish URLs without mod_rewrite! (AcceptPathInfo must be on in your httpd.conf though, so that PHP can access the $_SERVER['PATH_INFO'] variable)

Now I just need my partner to finish up CSS and Images and we will be ready to rock!

The authorization class will not take care of a login script or anything validating a user trying to login on your application. If you need a easy and fast login script you can read all about that on my SQL Login post. This class will take care of the page validation you need to do to make sure the logged in user is valid. This is done by introducing three different types: roles, resources and actions.

A role represents a user group for example guest, member, staff or moderator. A resource is easily explained as an object such as news, articles, users or games. Lastly the action is something you want to do such as add, delete, edit, view or list. With these three types we are able to specify authorization rules for various roles.

"Hum, I still don't get it!"

The PHP Authorization Class will help us define and set up rules for different roles. We can apply various action rules onto our resources which are, in the end, connected to our roles. We take a look at a example. Say we have three different roles defined for our application:

• guest - a visitor on the site which are not logged in.
• member - a logged in visitor.
• admin - the administrator

To simplify our application we only have one resource on the site which is:

• news

If we look at the overall actions we would like to do with this resource we might end up with something like this:

• view - look at a specific news item
• list - look at all news items presented as a list
• add - add news
• edit - edit news
• delete - delete news

Going back to our roles, we don't want to let the guest role adding, editing nor deleting news. In this example we don't even let guests view a specific news. As for a member they should be able to view, list and add news. The administrator should be able to do everything. We can achieve this by writing something like this:

$authorization = new Authorization();
$guest = 'guest';
$authorization->addRole($guest);
$authorization->addAccess('news', $guest, 'list');

$member = 'member';
$authorization->addRole($member, $guest);
$authorization->addAccess('news', $member, array('view', 'add'));

$admin = 'admin';
$authorization->addRole($admin, $member);
$authorization->addAccess('news', $admin, array('edit', 'delete'));

The above code implements the description of rules we stated a bit further up. We made a DSL to implement our authorization class if you will. Let's look at the code in more detail to see if we find anything interesting.

$authorization = new Authorization();

We create our PHP Authorization object and assign it to a variable named authorization.

$guest = 'guest';
$authorization->addRole($guest);
$authorization->addAccess('news', $guest, 'list');

We assign the variable guest the value of 'guest'. Then we add that variable to our list of roles our authorization class holds. The third line adds access rules. We start with providing the resource, the role and lastly the action. We could skip the first line and just add 'guest' instead of $guest. So, to make this very clear: These three lines of code gives the user group/role guest the ability to list all news on the site.

The next two sections are very similar to the first except for two things:

$authorization->addRole($member, $guest);
$authorization->addAccess('news', $member, array('view', 'add'));

In the first section the addRole method only took one argument and here we have two. What does this mean? It means that the first argument will be extended with the second argument. In this case, member will be extended with guest. This is really useful if member should have the same access as guest plus a few more. We don't need to add the list action to member because guest already has it. Basically guest is the parent of member (which is acting like a child). Everything we add to guest is also added to member even if we decide to assign more rules to guest after we have defined and created the member role. Pretty sweet huh?

The other thing that differ is the number of actions you can provide to the addAccess method. You can add just one action as a normal string or provide an array of actions. Also very useful if a resource has a lot of different actions defined.

So, the code above created our three different roles and we applied different action access for each of the roles on our news resource. Now we are able to query our Authorization class to see if a specific role have access to a specific resource with a specific action. We do this by using the isAllowed method.

echo $authorization->isAllowed($guest, 'news', 'list') ? 'allowed' : 'denied';

What do you think? Is guest allowed to list the news? The answer is yes. Can answer these:

echo $authorization->isAllowed($member, 'news', 'list') ? 'allowed' : 'denied';
echo $authorization->isAllowed($member, 'news', 'add') ? 'allowed' : 'denied';
echo $authorization->isAllowed($admin, 'news', 'add') ? 'allowed' : 'denied';
echo $authorization->isAllowed($admin, 'news', 'list') ? 'allowed' : 'denied';
echo $authorization->isAllowed($admin, 'news', 'comment') ? 'allowed' : 'denied';

And the answers:

Yes, member is extended with guest and guest is allowed to list news.
Yes, member is allowed to add news.
Yes, admin is extended by member and member is allowed to add news.
Yes, admin is extended by member and member is extended by guest and guest is allowed to list news.
No, admin is denied to comment on news.

Pretty cool! This can be used in your PHP pages where you need to check if the user is valid. For example in your header file to make sure unauthorized users don't get access to your pages and files. To know if you should add a comment form or not you simple check if the role in question have the access to comment. You are able to be very specific and you can show different parts of the page depending on the role type.

Since the class doesn't require a database it's 100% customizable. You can add your very own roles, resources and actions. All of this sounds pretty nice but how would it work in real action? I will give you a sweet example.

To be able to check if the role has access to the resource with a specific action we need to know the role, the resource and of course the action. It might sound like a huge amount of effort to get this to work, but it isn't! The specific role needs to be fetch from the user in question. Let's say we have a database with users and each user has a access type, say A-C. Either you can use these values straight of as your roles or we can translate them to understandable roles: A = guest, B = member and C = admin. This can then be saved in a session or in anyway you know as long as you are able to access it often and fast. The get our hands on the resource and action we can use the splendid mod_rewrite found in the Apache server software. If you don't know what this module does, I suggest you take a peak at my other post about friendly URL's. If we use the .htaccess wisely we will be able to fetch the resource and action from our URL.

.htaccess example:

RewriteEngine on
RewriteRule ^([a-z_]+)$ /authorization/$1/ [R]
RewriteRule ^([a-z_]+)/$ /authorization/index.php?resource=$1&action=list
RewriteRule ^([a-z_]+)/([a-z_]+)$ /authorization/$1/$2/ [R]
RewriteRule ^([a-z_]+)/([a-z_]+)/$ /authorization/index.php?resource=$1&action=$2

In this example my root is /authorization. The first two rewrites takes care of an example looking like this:

http://www.dosspot.com/games

It will first add a / to the end and reload and send the user to my index page with two get variables resource and action. We we haven't added an action the default action is list. The other two rules are activated if we have applied an action to.

http://www.dosspot.com/games/view/

Now we are able to fetch the resource and action out from our GET array and see if the role is valid for this page. If not we send him/her of to another page. So now we have two examples where we use the Authorization class inside a page using the isAllowed method to see if the user in question should be able to do various actions. Or we can use the URL to fetch the resource and action in question and validate. In our index.php page it might look something like this:

if(isset($_GET['resource']) && isset($_GET['action'])) {
$resource = mysql_real_escape_string($_GET['resource']);
$action = mysql_real_escape_string($_GET['action']);
$role = $_SESSION['role'];
}

if($authorization->isAllowed($role, $resource, $action)) {
echo 'You are allowed';
} else {
echo 'You are not allowed in here!';
}

Pretty simple put yet effective. But! There is more to it! Now we have a set of methods we can use to grant access to resources with different actions. If a user doesn't have the access s/he is thrown out from that page. We might want to apply a few of these access rules to every role avaible and we don't want to use extend, because there might just be one access we want to share, and we don't want to write it twice. How can we do this? Simple, we add null instead of a role in the addAccess method. By supplying null as the role the access rule will be applied to all roles, including roles added after the null access.

So let's say we want our guest to be able to access both the list and add news. The member role should just be able to list, not add. In this case we cannot extend the member role with the guest role since then the member role would be able to add news. Here is some code:

$authorization = new Authorization();
$authorization->addAccess('news, null, 'list);

$guest = 'guest';
$authorization->addRole($guest);
$authorization->addAccess('news', $guest, 'add');

$member = 'member';
$authorization->addRole($member);
$authorization->addAccess('news', $member, 'view');

With this slightly different code everyone will be able to list the news but the guest will be the only one able to add news and member the only one able to view a news. If this would be a real case it would be very bad, in this example though it shows the example pretty well. Notice that member isn't extended by the guest role.

The next thing we might be interested in is how we save the authorization object. We can do this with a simple session or we can store it using the serialize method in PHP. Since we have been working with session before we are going to use the serialize technique. Basically we are able to serialize an object meaning that we are able to save it on a file. We can then just unserialize the file and get our object back. By doing this we can write our authorization code in one file, serialize it and remove that code. Since the object is stored in a file we don't need to create our object everytime we want to access it, we just unserialize the file and the object with it's current state it presented to us. Sadly I'm a newbie working with the serialize method so if you know any problems or errors working with it, please let me know.

We simply use the save() method in the Authorization class to serialize our authorization object. We are able to provide a filename, by default it's saved as authorization. With our .htaccess file we are able to block everyone out from this file and deny everyone trying to access it. In every page we want to validate the user we simple do this:

include('Authorization.php');
$object = implode("", @file("authorization"));
$authorization = unserialize($object );

We have to include the class file and then we read the file and finally use the unserialize method to unserialze the object and we assign it again to our authorization variable. Now we are able to use the object exactly the same as we did in the examples above. Combine this with the .htaccess rewrite options you will find it rather easy to control the visitors using your system. It's easy, straight forward and pretty cool!

The download below provides everything you will need to run the authorization class, including unit tests!

• Download the PHP Authorization Class

RewriteEngine on

RewriteRule ^expressie$ link [L]

Maar je krijgt een HTTP/404 of een HTTP/500 dan moet je in de httpd.conf (staat in je apache configuratiemap) kijken naar <directory /path/to/www> naar AllowOverride. Als die op None of er staat een hele lijst achter, vervang die regel dan door.

AllowOverride All

Herstart Apache en het is gefixed! Nog problemen? Kijk eens in je error.log van apache. Kom je er nog niet aan uit? Zet dan de module Spelling uit en als het nog niet gefixed is, vraag het in #apache op irc.freenode.org.

... or like this with mod_rewrite disabled
http://telephotos.co.uk/index.php?object=photo&action=latest

Note that they both go to the same page. What is happening is the Orqi Loader is receiving the object and action parameters and then using them to look for a controller. First it will look in your nominated "_classes/_app" folder, then it will look in your nominated "_orqi/_app" folder for a default controller. If it can't find one then an error is returned to the screen of the ilk "Error: Class PhotoController not found."

The object parameter is the name of the controller and action is the name of the function in the controller. In the example above, this means Orqi will be looking to execute a function called "Latest" in a class called "PhotoController" which is in a file called "PhotoController.php".

Enable mod_rewrite

If you look in the config.php file you will notice a line like this ...

[sourcecode language='php']$this->app['mod_rewrite'] = true;[/sourcecode]

Set it to true to enable the nicer URL writing. Orqi will also produce nice URLs in functions like Controller::MakeLink()

NB: You MUST have the mod_rewrite module loaded on your webserver

.htaccess

Here is like the most basic .htaccess file you can get away with. It's here where the urls are redirected from "/niceurl/mycommand.html" to "/index.php?object=aargh&action=horridurl".

[sourcecode language='cpp']
RewriteEngine on
RewriteRule ^pages/(.*).html$ index.php?object=page&action=view&id=$1&%{QUERY_STRING} [L]
RewriteRule ^(.*)/(.*).html$ index.php?object=$1&action=$2&%{QUERY_STRING} [L]
[/sourcecode]

The File Extensions

If you want to change the url extensions in your urls just look for the following line in your config.php. The file extension in your config file must agree with the file extensions in your .htaccess file.

(My advice is leave it as html. I was using .orqi for a while before I realised it was an SEO suicide move)

[sourcecode language='php']$this->app['extension'] = 'html';[/sourcecode]

Habilite o mod_rewrite

a2enmod rewrite

OBS: Valeu Rodrigo!!!

Adicione as seguintes linhas no arquivo /etc/apache2/sites-available/default

...
CustomLog /var/log/apache2/access.log combined
ServerSignature On
RewriteEngine on
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [L,R]
RewriteLog "/var/log/apache2/rewrite.log"
RewriteLogLevel 2
...

Fonte

I have seen numerous posts on how to create "rewrite" scripts but found very little information on how to enable this feature in Apache 2.2.

Step 1: Uncomment the line with "mod_rewrite.so" from httpd.conf

LoadModule rewrite_module modules/mod_rewrite.so

Step 2: Search for the keyword ".htaccess" and change the AllowOverride value

AllowOverride All

Step 3: Restart Apache and check if module has been loaded (LoadedModule section in phpinfo())

Step 4: Create a test .htaccess in your root directory

Options +Indexes
Options +FollowSymlinks
RewriteEngine on
RewriteBase /
RewriteRule ^success\.html$ index.php [L]

Step 5: Type http://localhost/success.html in your browser (change port info based on your setup)

You should be able to see your index.php load up.

Recommended book:

To enable mod_rewrite in Ubuntu, you just need to write this command in terminal

sudo a2enmod rewrite

After enabling mod_rewrite you can write .htaccess file for your web application.

So what is .htaccess?
.htaccess file provides a way to make configuration changes on a per directory basis. It is a file contains configuration directives is placed in a particular document directory and the directives apply to that directory and all subdirectories thereof.

Some example:

Nice looking URLs (no querying) with pagination:
Suppose your url is: domain.com/article.php?name=title&page=5
You want to change: domain.com/articles/title/5/
Then write in .htaccess file:
RewriteRule ^articles/(A-Za-z0-9-]+)/([0-9]+)/?$ article.php?name=$1&page=$2 [L]

The rule is defined in regular expression. Here [L] means Last Rule. It's called RewriteRule Flags.

Another example:
Suppose your site has permanently moved to a new domain.
RewriteCond %{HTTP_HOST} ^www.domain.com$ [NC]
RewriteRule  ^(.*)$ http://www.domain2.com/$1  [R=301, L]

Here [NC] means case insensitive and its called RewriteCond Flags. [R=301] means moved permanently. Its called redirection header code.

• Download the WAMP software

We are going to start looking at the WAMP software first. After you have downloaded and installed the WAMP software you should find a short cut item on your Desktop. Click on that, in the right corner of your screen you should see some sort speed limit panel turning red, yellow and lastly white. If it doesn't turn white something is wrong with the setup. If you haven't changed anything from the default settings when installing the WAMP software. The activate the module making it possible to create friendly URLs we simple do this:

1. Left click on the WAMP icon in the right corner of the screen.
2. Move you mouse over the 'Apache' link.
3. In the popup menu, move your mouse over the 'Apache Modules' link.
4. Move down in the list by pressing the down arrow image until you find rewrite_module.
5. Click on the rewrite_module.
6. The WAMP software should restart, if it isn't do it your self be left clicking on the icon again and choose 'Restart All Services'.

So now we have the rewrite_module activated in WAMP. To active the rewrite_module without WAMP you need to go to your Apache directory, or make a search with the keyword httpd.conf. That file contains a lot of config options for your Apache HTTP server. Inside that file, search for:

LoadModule rewrite_module modules/mod_rewrite.so

That module will have a # in front of it, remove that and save the httpd.conf file and restart your Apache server. This is how you activate the rewrite_module in Apache and not via the WAMP software. Seems rather easy, right?

Okay, so what we have done so far is to activate a module we are going to use when we want to write friendly URLs. Friendly URLs you say? What is that? In my 12 SEO Tips post I talked about friendly URLs and how they are much better for web spiders, visitors and for yourself. The result after turning your unfriendly URLs into friendly once are this:

We turn this dynamically created, unfriendly URLs:
http://www.yourdomain.com/users.php?id=12

Into this friendly URL:
http://www.yourdomain.com/users/12/

Does that look a lot better than the first one? Especially if your website is targeting people with a lack of Internet experience. The simpler and cleaner your URL look like, the better. We will even have the chance of enter a name.html and turn it into name.php without the visitor knowing anything about it. Why should we like to  do that? Once again, it's better for the web spider and in the end your chance of being found in a search will expand.

So, the rewrite module activated and running, what do to next? We are going to create a file with the name .htaccess. This file is a configuration file working tightly with the Apache HTTP server.  This is how the Apache team describes it:

".htaccess files (or "distributed configuration files") provide a way to make configuration changes on a per-directory basis. A file, containing one or more configuration directives, is placed in a particular document directory, and the directives apply to that directory, and all subdirectories thereof. Read more about the .htaccess files"

Inside this file we are able to create patterns which will match the incoming URL. If the URL match any of our patterns we are able to transform the incoming URL into something else. What does this mean? It means that you don't have to change any PHP query strings code to transform your URLs. With the .htaccess file you are able to redirect your visitors to the correct page you want them to look at, but the address looks the same to them. Here is an example:

Your visitor writes:
http://www.yourdomain.com/users/12/

In your .htaccess file you do this with the incoming URL:
http://www.yourdomain.com/users.php?id=12

Looks like magic? It is! :) Naa, not really but it looks a lot nicer and, as I have told you several times now, it helps your search rankings.

The following will be an example of a .htaccess file. We will go through it line by line and see what it does.

1. RewriteEngine on
2. RewriteRule ^(/)?$ /index.php [L]
3. RewriteRule ^([^\/\.]+)\.html$ $1.php [L]
4. RewriteRule ^([a-z]+)/([0-9]+)$ /$1/$2/ [R]
5. RewriteRule ^([a-z]+)/([0-9]+)/$ /$1.php?id=$2

Line 1: Activates the rewrite module for this particular folder. This line is required for ALL .htaccess files.

Line 2: We rewrite http://www.yourdomain.com/ to http://www.yourdomain.com/index.php. The [L] at the end is telling the .htaccess file to stop rewriting if this pattern has been match.

Line 3: We rewrite all incoming .html files into .php. We do this because it's easier for visitors to enter .html instead of .php.

Line 4. We rewrite http://www.yourdomain.com/users into http://www.yourdomain.com/users/. We just add the extra / at the end to say: "Hey, this is how we like it". The [R] at the end is telling the .htaccess to continue the rewrite regardless if the pattern matched or not.

Line 5. Is rewriting http://www.yourdomain.com/users/12 into http://www.yourdomain.com/users.php?id=12.

Very simple. The pattern is using the cross-language script regexp, or regular expressions.  A good place to start looking at regexp if you haven't heard about it before is the link below:

• Read more about Regual Expressions

So by using the rewrite module found in the Apache HTTP server and creating a .htaccess file inside our main directory we can accomplish the friendly URLs task. Excited? I know I was the first time. Start right away!

According to me, before learning something new, we should take a look at why we need to do it and what's the use of it.

Use of URL rewriting:
1. Making website URLs more user and search engine friendly.
2. Preventing undesired "inline linking".
3. Not exposing the inner workings of a web site's address to visitors

So let's begin...

Project Name: url_rewriting
Dir. Structure: url_rewriting
- cache
- configs
- libs
- templates
- templates_c
- .htaccess
- other php files

What we want to achieve:
here we want to convert the following url
from,
http://www.orkut.com/UniversalSearch.php?origin=box&exp=1&q=php
to
http://www.orkut.com/box/1/php/UniversalSearch.html

How we can achieve:
we need to first create a file "function.seo_optimise.php" in "smarty/lib/plugins/", so that smarty will treat it as its own function without any hassal.

function smarty_function_seo_optimise($params, &$smarty)
{
// we will add code here later...
}
?>

Done... 50%

Now secondly, we have to create a .htaccess file in the directory structure as shown above. And add following...

php_value error_reporting 7
Options +FollowSymLinks
RewriteEngine on
RewriteRule ^(.*)/([0-9]+)/(.*)/UniversalSearch.html$ UniversalSearch.php?origin=$1&exp=$2&q=$3

Please note that, (.*) suggest the type of text we are sending to perticular querystring. Like for origin querystring, we are going to send anything including characters & numbers, or in case of exp querystring, we are going to send only numbers thats why we have used ([0-9]+) in order to restrict the querystring value to the numbers only.

Done... 70%

I know, you are confused now, because you are thinking that how smarty will know, (.*) for origin, ([0-9]+) for exp and (.*) for q. Do not worry, thats we have created "function.seo_optimise.php" file above. Now, open this file, and write the following code... please note that here we are going to send three querystrings to the page thats why we have to pass three parameters to the function also. These are the three parameters..
function smarty_function_seo_optimise($params, &$smarty)
{
/* This is for three querystrings */
$origin = $params[origin];
$exp = $params[exp];
$q = $params[q];
/* This is to recognise the page to which we are going to rewrite */
if($params[type] == 'universal_page')
{
if($params[urls] == 'Enable')
return $origin.$exp.$q."/UniversalSearch.html";
else
return "UniversalSearch.php?origin=".$origin."&exp=".$exp."&q=".$q
}

}

Done... 80%

Now let me explain you, this smarty function will transform our old url to new like this... http://www.orkut.com/box/1/php/UniversalSearch.html Ok then, time to spell the beans... to convert that url we have to write following in .tpl file.

{seo_optimise urls=$seo_urls origin=box exp=1 q=php type=universal_page}

<a href="http://www.blogger.com/%7Bseo_optimise%20urls=$seo_urls%20origin=box%20exp=1%20q=php%20type=universal_page%7D">
Click me
</a>

here is a explaination...

$seo_urls => Enable/Disable

when the page get loaded, that seo_optimise will pass the supplied parameters to the function of a same name created in smarty/lib/plugins/function.seo_optimise.php.

1. First, it will add the passed value to appropriete variables as mentioned above in this php file.
2. secondly, it will check which page you want to rewrite using "type" variable.
3. If it is "universal_page" and $seo_urls is "Enable" then it will return the url like http://www.orkut.com/box/1/php/UniversalSearch.html or if $seo_urls is "Disable" then it will return the url like http://www.orkut.com/UniversalSearch.php?origin=box&exp=1&q=php
Done... 100%

Using this way we can rewrite any url in any ways you want, just do not forget to enter the old url & new url in .htaccess file.

From the Blogosphere.

DVLabs put a post up yesterday that is the first in a weekly feature that Cody is starting regarding reverse engineering tips and tricks. The first post takes a look at the Rhapsody Media Player. Interesting stuff.

Rafal gives us a real-world example of XSS. Worth a look.

Frank Cassano has part 2 of his Assessing your Organization's Network Perimiter available. Part 1 is here. Good stuff.

Rich points out that it in the world of SQL injection, it is very important that collaboration occur with our database admins and architects to ensure we are restricting rights appropriately.

Lori points out that dynamic resource obfuscation can help us make the target much harder to find, let alone hit for the evil haxors out there. She is not promoting security through obscurity, but suggesting that we can actively make it very difficult for an attacker to figure out what to attack.

Donald Donzal, the editor in chief at the Ethical Hacker Network has posted a recording and slides of the presentation he gave at the Sans What Works in Pen Testing Summit titled "Remodeling your career for little to no money down". I've got my copies downloaded and will be listening soon.

Via Xavier are /dev/random, Michael Boelen, the creator RootKit Hunter, has released a new tool that should be welcomed by all UNIX folks, Lynis: Security and System Auditing Tool. Go take a look.

Adam Dodge has a post up over at Security Catalyst that reminds us to keep in mind the samples used when reading a report. This applies to every report you might read that has statistical data in it, but he is specifically talking about the number of reports that have come out recently regarding breach statistics.

0x000000 has updated the mod_rewrite signatures used as a poor man's web application firewall to add some banner obsfucation stuff. If you haven't seen the full set, poke around on the site. It is good stuff.

Finally, the folks at wartchfire have an article up talking about cross environment hopping. This is where an XSS vulnerability is exploited to hop to another service hosted on the target client machine. Not cool. Go read it...twice :)

I will be posting the interesting bits from news sources a little later today.

Kevin

Technorati Tags: reverse engineering, xss, perimiter, sql injection, resource obfuscation, career, lynis, breach reports, mod_rewrite, cross environment hopping

RewriteBase /

Says that all the rewriting will start from the directory the .htaccess file is located in

RewriteCond %{REQUEST_FILENAME} !-f

Continues to next rewritecond if the requested file does not exist

RewriteCond %{REQUEST_FILENAME} !-d

Continues to rewriterule if the requested file is not an existing directory

RewriteRule . /index.php [L]

Rewrites any request with 1 or more characters to /index.php, which launches wordpress and handles all redirections and what to display

If you want the mydomain2 to be handled differently, create an .htaccess file in the mydomain2 sub-directory with its own errordocument. ie.

ErrorDocument 404 /mydomain2errors.php

Or, alternatively, you can turn off the wordpress htaccess rewriting for that subdirectory.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !^/mydomain2subdirectory.*$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Rewriting dynamic.php?id=12 to dynamic-12.html

Redirection in which .php extension is hidden from the useragent’s address bar and dynamic url.
code>RewriteEngine on
RewriteRule ^dynamic-([0-9]+)\.html$ dynamic.php?id=$1

Rewriting dynamic.php?id=7 to dynamic/indexes-access/7.html

Alwaysdisplay the main keyword in the URL. In the following URL rewriting technique you can display the name of the dynamic in URL.

RewriteEngine on
RewriteRule ^dynamic/([a-zA-Z0-9_-]+)/([0-9]+)\.html$ dynamic.php?id=$2

Redirecting non www URL to www URL

If you type yahoo.com in useragent it will be redirected to www.yahoo.com. If you want to do same with your website then put the following code to .htaccess file.

What is benefit of this kind of redirection?? Please check the post about SEO friendly redirect (301) redirect in php and .htaccess.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^htaccessrewrite\.com$
RewriteRule (.*) http://www.htaccessrewrite.com/$1 [R=301,L]


Redirecting the domain to a new subfolder of inside public_html.

Now you can point both domains to /www/ directory as your DOC_ROOT.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^rewrite\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.rewrite\.com$
RewriteCond %{REQUEST_URI} !^/www/
RewriteRule (.*) /www/$1

Now, the problem is that FrontPage uses the .htaccess file (which the WordPress mod_rewrite rules must access) for its "publishing" and "web authoring" configuration. As soon as the WordPress mod_rewrite code is added to the file, two things happen — the permalinks don't work and the Frontpage Server extensions become corrupt.

I have tried countless ways to get around this, including trying to use rewrite rules that "ignore" the %{HTTP_USERAGENT)% used by FrontPage, to using a second AccessFilename .wpaccess to the httpd.conf file, and a host of other things, and nothing worked to allow use of FrontPage and management and use of permalinks in WordPress at the same time.

The solution is actually simple, and I figured it out by accident.

If you are using, or wish to use FrontPage (or if your hosting package is pre-configured that way) along with WordPress, you'll need to take the following simple steps on your server or have your hosting company do them for you.

Microsoft FrontPage creates the following directory

_vti_bin

Nested within that it creates both

_vti_adm

and

_vti_aut

In addition to in your site (or WordPress) root folder in all of those directories you will find additional .htaccess files.

In all three of these directories AND in the root directory, at the top of ALL of the .htaccess files you simply need to add one line:

Options +FollowSymlinks

There may or may not already be a line in each like

Options None

Edit and save each .htaccess file and you're done. Now everything works perfectly, including FrontPage, AND the permalinks of your choosing.