I am currently building a multi-site content management system for a client which will support a separate domain name per web site. When the web site the domain is pointing to is not found, the client would like to simulate a failure in the browser as evidenced in the screenshot below.
I'm not sure if this is possible to do in PHP. Does anybody have details on this or any advice?
Related
I want to make php script that replace the execution of this kind of a link:
YM! Iron Man
So when the php script is called/executed, it will open Yahoo Messenger application window that prepared to send IM to tonystark.
Can I use header instead? but what type of header it would be?
The ymsgr is a custom protocol that is configured to start Yahoo Messenger, which is able to parse appropriate parameters following the ":".
This question (how do I create my own URL protocol?) may be relevant as it shows how it is possible to add custom URL protocols. The example is for Windows only but it must be a similar approach for other operating systems.
To make a story short, ymsgr: opens Yahoo Messenger because your system can recognize it and that Yahoo Messenger is its associated action.
The ymsgr in the link is a predefined protocol on your PC. Just like http, https and ftp are protocols known to your system. If you want to create custom protocols to be handled by the pc of your visitor, you must have them install something that will add the protocol to the system. Only then will the pc know what to start.
A good example of a non-standard installed protocol is skype. The links to add a user to your skype or chat with them only works if the visiting person has Skype installed. Otherwise an error occurs on the computer; "I don't know this protocol, what to do?"
So using a header to replicate the link will not work. Simply because your PC will not understand a header; it will only understand links to protocols, as if you are opening a page (http,https), email application (mailto), ftp programme (filezilla, unless handled by browser) etc etc.
I have developed a website application that includes a custom built CMS and PayPal payments etc...
My client already has hosting for his main website via the developer of that site.
I wish to host the new application under a subdomain such as:
application.website.com
I have reservations about storing my complete source code on the other web designers server.
Is there a way that the code can remain on my server but with the required subdomain or somehow password protect the folder?
Thanks for the help.
You might be able to store your source code on your server and use the PHP include function to get the pages on your client's website to use the code on your server. I've not tried this so it may not be possible for PHP to communicate between two servers like this, but give it a go and see what happens.
I'm currently building a simple web application in PHP that other company's can use as one of their services. I want to host the application myself and not install it on one of their servers, but i do want the accessibility that that would offer. Example:
www.mywebapp.com is where i would host the web application.
www.company.com would be the domain name of the client.
webapp.company.com should redirect to www.mywebapp.com/?c=company. Upon navigation, webapp.company.com/view.php?v=test would also be redirected to www.mywebapp.com/view.php?c=company&v=test and so on upon further using the web app.
Can someone explain how i can achieve this and if this is the best option considering my requirements?
I recommend that you switch to implementing an API. That's how this problem is solved by many corporations. They simply have an API key that will let your server know what client they are and therefore what to serve them.
Resources on API's:
Google Tech Talk: http://www.youtube.com/watch?v=aAb7hSCtvGw [1:00:19 long]
http://blog.programmableweb.com/2011/01/06/from-the-trenches-web-api-design-best-practices/
Directory of some existing API's: http://www.programmableweb.com/apis/directory
I think your idea IS possible if both servers are set up correctly, but doesn't it feel wrong to you?
You would need to have an 'a' record for both domains pointing to the same server
http://corz.org/serv/tricks/htaccess2.php?page=all#section-rewrite_sub-domains
I have a file that is being linked to from other sub websites.
The file: http://site.com/file.img
Website A linking to it <img src="http://site.com/file.img"></img>
website B linking to it <img src="http://site.com/file.img"></img>
I need to reliably identify which of these websites has accessed the file, but I know that $_SERVER['HTTP_REFERER'] can be spoofed. What other ways do I have to reliably confirm the requester site? By IP, get them to register an IP? not sure. setup an API key? What options are there?
If a website is only linking to a file, the "website" itself will never actually access your image. Instead, the client who's viewing the site will make a request for the image.
As such, you're depending on information sent by the client, which is completely out of your control and not reliable at all. If you have the opportunity to set some sort of unique cookie on the client, you may be able to use this in some fashion for extended identification, but even that won't be reliable.
There is no 100% reliable solution.
Getting the referrer is the best you can do without getting into complicated territory.
If you don't mind complicated, then read on: set up your Web server to serve file.img only to Website A and Website B, then require that Website A and Website B set up a proxy configuration on their end that will retrieve file.img on behalf of their visitors.
Example:
A visitor to Website A loads a page that contains an image tag like <img src="http://websiteA.com/file.img"/> (note reference to Website A rather than your site). Client requests file.img from WebsiteA.com accordingly. Website A is configured to proxy requests for the path /file.img to your server, http://site.com/file.img. Your site verifies that it is in fact Website A that is requesting the image and then serves it to Website A's proxy. Website A then serves it to the visitor.
Basically, that makes it a pain for Websites A and B, gives you a performance hit, and also requires further configuration on your part. But I imagine that would satisfy your requirement.
Have a look at how OpenID relying is implemented, it allows one site to authenticate against another. The protocol specification will give a hint at the effort and overhead required to reliably implement such a scheme.
http://googlecode.blogspot.com/2010/11/googles-sample-openid-relying-party.html
I am working on a browser based application that will have many users. The catch is that every user should have their own customized login page, but the actual application is the same for everyone, and needs to be in a central location.
The login page is static. That is, if we have a user that requires a separate login, we will make a separate landing page for them, lets say at user1.application.com, that will have a blue background. User two will be handed a url to user2.application.com, which will have a green background. The application does not have to dynamically change the look of the login page, that will be static and managed on a higher level.
What is the most secure way of doing this?
Would it make more sense to have a copy of the application for each user, and keep the database centralized?
The projected number of users is not very high, probably around 20-80.
Thank you,
I can give you instructions on how to do this using Microsoft IIS and ASP.NET. Other servers and programming languages still apply, but the specifics will be a little different.
You'll need to have access to your DNS settings. Create a DNS entry for *.applicaiton.com. We do this as a CNAME record that points to our www domain record that is registered as the A record that is associated with the IP Address.
Option 1:
In IIS 6, create a web site and modify the Host Headers (web site Properties, Web Site tab, "Advanced..." button in the "Web site identification" section). Add an empty host header. This will cause that web site of IIS to answer all requests for all domains associated with the IP Address it is listening on.
Then create a default page and in the code behind, you'll have logic that looks at the Request.UserHostName of each request. It should return "user1.application.com" or "user2.application.com" or perhaps "www.application.com". You'll then have to parse that string and do all the dirty work to load the appropriate page.
Hmm, well, that's how you would do it dynamically, with one web site. Re-reading your question, you talk about "static" login pages. For that you have two options. You can create the static login pages and have your dynamic page read those files and send them down as the response, or option two would be...
Option 2:
In IIS, create a new web site for every user. Modify the host headers as described above such that each web site only have one host header that is equal to the user's login. Do not have a web site with an empty host header. You'll have to create a web site and add the host header for every new user, manually.
Neither option may sound very elegant, but Option 1 does work rather well. We are using it in a similar fashion to host multiple "skins" of our application.