I was wondering how Wordpress and other random forums and sites, like facebook, create like phantom directories? Eg, a blog might have http://www.joesblog.com/2010/11/12/this-is-my-post.php
Does that file and directory resource actually exist? Also, how does Facebook, for example, have like http://www.facebook.com/-usernamehere- ? Is that a physical directory, or is it simply a scripting trick? How can I do this with PHP?
That kind of functionality is normally achieved by instructing the web server to "link" certain URL patterns to a specific controller.
See .htaccess, for example.
EDIT: This article on Rewrite engine might also help.
So no, no directories actually exist. The web server receives a request for a specific URI and redirects that request to a delegated controller (that can be a PHP script, for example) that in turn returns a result based on the URI and action requested by the user.
PHP can certainly handle this, but it's the web server that needs to be instructed on how to handle those types of request.
If you're using apache you might want to take a look at some mod_rewrite tutorials.
Related
Say I have a PHP app (WordPress) at http://example.com/.
It is not a simple blog. It is a large app with thousands of pages, multiple custom post types and "themes within a theme" to handle all of the custom content.
I want to integrate this with another PHP app (for this example let's say silverstripe, but it could be anything) in a way that will allow me to replace things in stages because I don't want to have to wait months until a totally new app is finished before deploying anything.
The problem is that this is a 10yr+ old site and has many legacy URLs that must be maintained. That means redirects are not allowed(for certain URLs) and I need either app to be able to respond to the same URLs that currently exist. Can't add in /wp/ or anything like that. The URLs need to be identical.
So for instance we currently have a page at http://example.com/page.html that is being generated by WordPress. I would like to replace this with a page that is generated by silverstripe.
Is there a way to configure Apache or Nginx so that if the silverstripe app understands the request (has a route defined) for http://example.com/page.html it will be generated by silverstripe and if it doesn't understand the request it will "fall back" to WordPress and be served from the same URL http://example.com/page.html by WordPress. Not http://example.com/wordpress/page.html
Thanks!
Apache mod_rewrite's "passthrough" can handle this. It's frequently used for URL shortening for SEO purposes (e.g. to rewrite /some/crazily/long/path to /short), and could also be used by you to use /page.html as /wordpress/page.html, e.g:
RewriteRule ^/page.html$ /wordpress/page.html [PT]
So go ahead and setup the separate directory for your wordpress instance, and use RewriteRule. The URL will still show up as '/page.html' in the brower's location bar, but it will serve '/wordpress/page.html'.
More on PT: http://httpd.apache.org/docs/2.4/rewrite/flags.html#flag_pt
This will take care of your 'served from same URL' requirement. As far as serving it only if you can't serve it from the first app, take a look at this existing thread: Redirect requests only if the file is not found?
I'm using htaccess to rewrite and redirect www.mysite.com/index.php?id=# to friendly urls like www.mysite.com/news. So all news-articles will be written as www.mysite.com/news/article1, etc.
Now I'm blocking off all directories on my server that it doesn't need to index with robots.txt. Since I'm using a cms these are directories like /core, /managers, /connectors, etc. But since the www.mysite.com/news directory doesn't actually exist, but is rewritten with htaccess, will blocking off all the directories like /core, etc. still allow a crawler to index my website?
So basically what I want to know is: does a crawler see my website urls as they are after they're rewritten? Or does it still need access to the other directories of my cms, like /core to be able to index my pages?
No, the rewritten URL is an internal mapping process only. It is only used by your web server to determine how to treat the user-friendly URL it receives.
The same way the URL remains unchanged in a browser address bar, the process is invisible to the client, be it a web browser or a bot.
URL Rewriting is not to be confused with Redirection. In the latter case, a client request receives a "301 Redirect" response containing the URL where the actual resource resides. This results in a second request from the client to the redirected URL. Then by definition the client will be aware of this process.
I'm wondering how I can store tags in a url without the ? and without keys.
eg. Google Product forums does this: http://productforums.google.com/forum/#!topic/analytics/8qtK861a0iU
Each topic wouldn't have it's own directory and so a server side script determines which topic to show visitors.
Does anybody know how it is possible to do this with PHP?
Thanks
Google use a range of software to do this. one of which, can be done using .htaccess used on Apache servers (not IIS)
This is called modrewrite. A URL below can show an example of such tasks:
http://roshanbh.com.np/2008/03/url-rewriting-examples-htaccess.html
Do start learning this, upload a file called .htaccess to your Apache driven webserver.
I understand that there may be other questions regarding vanity urls but everyone i see has a different code that i guess does the same job. Therefor i do not understand what rules are best for my personal question, that being said here is my question.
I simply want to create this,
127.0.0.1/website/profile.php?id=1
To this,
127.0.0.1/website/profile/Admin
My sub questions are also,
I understand the .htaccess file has to be in the root directory, but is that the root of my website or my xampp htdocs?(e.g c:/xampp/htdocs/ or c:/xampp/htdocs/website)
Using php should i make the conversion between id to username for the URLS on a seperate file then redirect to the requested user's page?
Thank you for reading, i just can't seem to get my head around .htaccess!
Root directory of your website.
No need for redirects. The way it works is that you can map every section of your URL to a URL parameter. For example, http://localhost/profile/Admin is really interpreted as http://localhost/website/profile.php?username=Admin. Only users will see the vanity URL; PHP will still see the URL parameters. In your case, the .htaccess rule will look something like ^profile/([0-9]+)$ profile.php?username=$1 (I obviously don't know for sure since I don't know the architecture of you site).
On a side note you might find Virtual Hosts interesting. It's a way of being able to create your own local domain for your site, for example http://my-local-website instead of using http://localhost/website or waiting to test in production.
More info here: http://sawmac.com/xampp/virtualhosts/
There is this PHP script on my website which I don't want people to be able to run by just typing its name in the browser.
Ideally I would like this script to be run only by registered users and only from within a Windows app (which I will have to provide). Can this be done ?
Alternatively, how can I protect this script so that it can only be called from a specific page or script?
Also how can I hide the exact URI from appearing on the address bar?
Thanks !
If you are running Apache for your webserver, you can protect it with a username/password combo using .htaccess. It takes a little configuration if your server is not already configured to allow .htaccess. Here are the Apache docs.
If you need authentication based on application-specific factors, you can put something at the top of your script like
<?php
if(!$user->isLoggedIn()) {
// do 404
header('HTTP/1.0 404 Not Found');
}
Do you have a question about how you would implement isLoggedIn?
You can also use mod_rewrite to rewrite URIs, and those directives can go inside your .htaccess as well. mod_rewrite can rewrite incoming requests transparently (from the browser's perspective) so a request for /foo/bar can be translated into secret_script.php/foo/bar. Docs for mod_rewrite.
However you decide to implement this, I would urge you to not rely solely on the fact that your script's name is obscure as a means to secure your application. At the very least, use .htaccess with some per-user authentication, and consider having your application authenticate users as well.
As Jesse says, it's possible to restrict your script to logged in users. There are a large number of questions on this already. Search for PHP authentication.
However, it is not possible to restrict it to a single application. It is fairly simple to use a program like Wireshark to see exactly how the program logs in and makes request. At that point, they can reproduce its behavior manually or in their own application.
There are a variety of different ways that you could go about securing a script. All have pluses and minuses, and its likely that the correct answer for your situation will be a combination of several.
Like mentioned, you could lock down the account with Apache...it's a good start. Similarly, you could build a powerful 'salt-ed' security system such as this: http://www.devarticles.com/c/a/JavaScript/Building-a-CHAP-Login-System-An-ObjectOriented-Approach/ If you use SSL as well, you're essentially getting yourself security like banks use on their websites--not perfect, but certainly not easy to break into.
But there are other ideas to consider too. Park your script in a class file that sits inaccessible via direct URI, then do calls to the various functions from an intermediary view script. Not perfect, but it does limit the ways that someone could directly access the file. Consider adding a "qualifier" to the URL via a simple get--have the script check for the qualifier or fail....again, not a great solution on its own, but one additional layer to dissuade the bad guys. If you have control of who's getting access (know exactly which networks) you could even go so far as to limit the IP's or the http referers that are allowed to access the file. Consider setting and checking cookies, with a clear expiration. Don't forget to set your robots file so the browsers don't stumble upon the script your trying to protect.
A while back my company did a membership app using Delphi on the front end, talking to php and MySql on the backend....it was a bit clunky given that we were all web application developers. If you're so inclined, perhaps Adobe Flex might be an option. But ultimately, you'll have to open a door that the application could talk to, and if someone was determined, theoretically they could dig through your app to find the credentials and use them to gain instant access to the site. If you're going the desktop app route, perhaps its time to consider having the app avoid talking to an intermediary script and do its work on the local machine, communicating the db that sits remote.
you can use deny access on .htaccess on a folder with a php authentification that will redirect to those php file