我正在使用散列值来防止垃圾邮件并通过更改 ID 号直接访问用户配置文件。这是用户注册时给定的唯一整数值,存储在数据库中并且永远不会更改。
个人资料链接如下所示:
example.com/profile.php?id=xxx&hash=xyz
我想用用户昵称重写 URL,如下所示:
example.com/nickname
但是在 URL 中使用哈希值时我该怎么做呢?我找不到这个的样本!
我正在使用散列值来防止垃圾邮件并通过更改 ID 号直接访问用户配置文件。这是用户注册时给定的唯一整数值,存储在数据库中并且永远不会更改。
个人资料链接如下所示:
example.com/profile.php?id=xxx&hash=xyz
我想用用户昵称重写 URL,如下所示:
example.com/nickname
但是在 URL 中使用哈希值时我该怎么做呢?我找不到这个的样本!
If I understand you well:
You want to provide to the end user several url:
/profile.php?id=<id>&hash=<hash>
/<nickname>
They would all be available but the 2nd one would be the preffered way.
there is a problem with the /<nickname>
type of url, if a nickname is "foo/bar" or "index.php" or "admin", etc the problem is that some nicknames may cover some other valid urls. So at least a better format for vanity url would be:
/nick/<nickname>
or /user/<nickname>
If you do not want that you'll have to ensure that nicknames will never match any valid path to any other asset.
Then you'll quite certainly have to handle special characters in nicknames, spaces, "/", chineses utf16 chars, windows specific encoding, etc. This usually targets the application server as the best tool for handling the nickname and finding the real user page to show.
Now let's take back the first url format : /profile.php?id=<id>&hash=<hash>
, you use the hash to avoid direct access to user profile by altering the id. And you said every user have a nickname. I would say why not simply only using the vanity format and forbid direct access to the profile.php script with an id? You could hanlde all user profile acess internally and never provide such entry... anyway, let's say you still want to be able to access a user profile by id.
This access url is generated by your application. Your application is adding the hash after the url when providing the link, (maybe the hash is a salted hash based on the nickname?). So your application can store for each user the user hash. And then in profile.php you always check that the hash is the right one for this id. All this is managed in your application, not in the http server (apache). The http server and his rewriting tools is, in my humble opinion, not the right tool to make the match, it cannot easily match your outgoing links and alter them, it cannot easily catch your ongoing links and transform them in the right profile.php+id+hash form.
So the only rewriteRule I would use is one catching nickname based entries and sending them internally to a profile redirector script in your application. Something like:
RewriteRule ^/nick/(.*)$ /profile-by-nick.php?nick=$1 [L,QSA]
Then inside this php script you can do what you want to provide the same task as in profile.php. With a well written php app it's quite easy to provide internal redirection inside the application, do not send a real http 302 redirection on the profile.php script. use functions, classes, etc.
If really you want apache to directly send the right profile.php?id=&hash= url to your application (maybe because your php code was written by a poney :-) ) then you could check RewriteMap as suggested by @David Ravetti and get an external script running as a daemon and providing the nickname->id+hash mapping to apache. But it seems really more complex, not the right place to handle it. This script will need rights to load you database, and informations on table structures that your application already have.