I have the domain test.com(just as an example), which I have bought from namecheap. I have redirected the domain to http://app-test.rhcloud.com/. However, when entering test.com in my browser I still can see http://app-test.rhcloud.com/ in the browser instead of test.com. Any recommendation how to clean that up?
I appreciate your answer!
You need to use a cname for your application, not a redirect. A redirect just tells the browser, now go to this domain instead. Check out this blog article for the correct way to setup what you are trying to do: https://www.openshift.com/blogs/custom-url-names-for-your-paas-applications-host-forwarding-and-cnames-the-openshift-way
Related
I'm creating a website, and I have some trouble configuring my domain. What I mean by that is, I have the domain (myurl.com). How can I make it so that the URL (example.myurl.com) redirects to myurl.com? It would be greatly appreciated.
(google sites)
It depends on your web server. If its apache, look into name based virtual host, ServerName and ServerAlias.
You also need to configure your DNS. You can also use a PTR or CNAME (canonical name) to point lets say www.mydomain.com to mydomain.com. You can add as many of these in DNS (Name Server) as you well please.
What you are looking for is called a sub-domain.
I couldn't tell you off hand how to set it up, but hopefully that helps you refine your google searches on the matter.
I have 2 UI applications (node and ejs server side rendered).
Say
www.example.com and www.abc.com
I redirect user from Application A to Application B using a simple button with href.
Now the Referrer in the Request header is Application A url which is expected.
Also after redirection to Application B. If the user navigates to the child pages, then the referrer is Application B url, which is also expected.
But the problem/issue is that from the child page of Application B, if the user clicks on browser back button then the referrer is Application A url which is not expected. Ideally the referrer should be application B since it's an internal redirection within the application.
This case is tested in Chrome and Firefox both behaves in a similar way.
I have to perform operation based on the right referrer. Please suggest a fix or correct me if my understanding is wrong.
Thanks in advance.
The Back button's function is to restore the previous page to the browser. That page arrived at the browser with its referer set to application A. So if the Back button does anything it's going to give you the old referer. That can't be changed. Because cybercreeps.
Your best bet is to handle the case some other way. For example, you could use session storage to set some kind of browser flag saying you've already seen the first referer.
I'd like to redirect particular Internet Service Providers to other websites when trying to access my website (I'm a html/css newbie).
I'm not sure how to do this or whether it is possible with html/css(?), should I be looking at another language or is there a setting in Amazon Web Services that allows me to block or redirect specified ISPs.
Any ideas are very much appreciated.
I'm reminded of a story where a competitor visited a company's website to scrape pricing information. So, the company changed their website to show different prices to their competitor!
So, it seems your goal is "when requests come from IP address XX, don't give them access to my website".
Here's a few ways to achieve this:
Block traffic from a single IP using Network Access Control Lists (NACLs) — very simple and effective!
Or, you can configure rules using Advanced Request Routing for AWS Application Load Balancers
Or, you could use AWS Web Application Firewall (WAF) to block specific IP addresses
I think it would be more fun to send them to an alternative website with false information, so they don't realise you are actually blocking them!!
I reread your issue and you only wanted specific providers, this would redirect for everyone. this wont work if popups are disabled
<html>
<body onload = "forwardFunction()">
<script type="text/javascript">
function forwardFunction() {
window.open("https://www.google.com","_self");
}
</script>
If you can read this something went wrong.
</html>
This is somewhat of a newbie question I'm sure and I hope the community will excuse me for not knowing this (or not knowing the appropriate search terms to resolve my question).
So, this is the deal: I'm running a small webpage with a small amount of visitors. I've written the whole page in HTML and CSS myself and I host it in my private DropBox (http://dl.dropbox.com/u/3394117/Hemsida/Psykofil/Index.html).
I've bought the domain name "www.psykofil.org" from Loopia (www.loopia.se) and I've directed this domain to the index.html file referenced to above.
Now, this is what I want to happen: I have three different places you can go to on the page (you choose where to ge through a menu on the left). When one of these links is clicked, it takes the user to another .html-file. What I would like to happen here is that this is seen in the adress field so when he or she clicks on "x", it should say www.psykofil.org/x on top. Also, when he or she navigates away from the webpage through a hyperlink I would like the adress field to update to show the new location. Right now, no matter what the user does, it always says www.psykofil.org in the adress field.
I probably should mention that my options (freely translated from swedish) when I go to the configuration of my domain name at Loopia is the following:
DNS
Parking
Forwarding (the one I'm currently using)
Send to an external URL
(Unavailable because I don't have a web hotel with Loopia) Point to another domain in the account.
(Unavailable because I don't have a web hotel with Loopia) Own homefolder for webpage.
That's because your page is inside a <frameset>, so the address bar will never update.
You say "I've directed this domain to the index.html file referenced to above." It sounds like you've set up 'domain forwarding.' Framesets are often the 'trick' hosts use to keep the same URL - embedding the pages you're 'forwarding' to in a frameset. It's called "domain masking." See http://www.hostingmultipledomainnames.com/domainforwarding.htm for a description of how it works.
If you upload your actual html files to your site root, that should do the trick. If you're not sure how to do that and you're a new webmaster, you may want to be in touch with your web host's support. Otherwise, if you want to have that domain, but keep your files in your dropbox account, your options I believe get complicated (things like reverse proxies).
UPDATED:
Typically, when people create a website, they do three thing: register a domain, buy a web hosting account, and then associate their domain with their hosting account. You've done the first part, and have found a clever way of managing the second part, but you haven't done the third part.
The process is like this:
You register your domain. I.e., you pay $10-30 a year for the exclusive right to a given domain name. Registering the domain means that when people type 'http://mysite.com' into their browser, your domain will come up. However, it's just a placeholder - there isn't any real content there. All your files and images need to be uploaded to a server in order for people to see them.
You purchase a web hosting account. Or in your case, you upload your files to a publicly-accessible server, which has the advantage of being free. You then upload all your content.
This is the part you're missing. You now need to associate your domain name with your hosting account. This typically happens without your intervention when you purchase both your domain name and your web hosting account through one company.
However, if you acquire them separately, you need to do two things:
a. Log in to your domain registrar and point the domain name to your server for your web hosting account. This is a signal to the Internet - hey, when you type in the domain name 'http://ssss.com', go to this server.
b. Log in to your web hosting account and "park" the domain at your account. This may be hard to understand at first, but basically, just telling the Internet to go to this or that server when typing in your domain name isn't very useful.
If that's all we needed to do, I could just register http://my-amazon.com and point my domain to Amazon.com. Then people could surf Amazon.com as http://myamazon.com and I could get rich from selling this now incredibly popular domain.
But that doesn't work. In order for me to actually browse the web hosting account through my domain name, I need to "add" the domain name to my hosting account. Dropbox doesn't let you do that. It's a file-sharing system, which you've cleverly used as a web host. However, you'll never be able to log into Dropbox and park your domain there, because that's not what they do.
Summary: You can think of this process like a pass in basketball. You can throw the ball by sending the user to a server, but the server has to catch it. In order to catch the ball, the server needs to know it's coming.
Your domain registrar is 'faking' this process by adding one page to its own server, which links to "http://dl.dropbox.com/yourpage/etc/etc/Index.html". This way, your domain registrar doesn't have to worry about hosting all your content and the headaches of technical support and server space.
The downside is, you don't have a webhost that allows you to park a domain at the moment. The upside is you're saving about $60-100 per year (it might be more or less in Sweden), which is what a basic "shared" hosting account would cost.
You can decide if having distinct webpages (http://psykofil.org/contact.html" etc), is worth it for you, or whether you're fine for now with the very low-cost solution that isn't perfect but at least allows people to access your site. What you've come up with is actually pretty cool, but it does have some limitations.
Finally: If you do want to go ahead an buy server space so you can host your site, it will be less of a headache to buy it through Loopla, if the price and service are good. Typically, you are given the option when making the purchase of linking your account to your already-registered domain name. Then all you need to do is use an FTP program like Filezilla to upload your content to your account, and you're done.
It seems your host is "masking" the URL, meaning actual index.html page located at "www.psykofil.org" is in fact, loading your index page located via dropbox into an "iframe" , hence your main URL does not change to reflect the changes.
Solution: Upload your file to your main host and change the default index file that has iframes with the dropbox index file.
I believe it's because you're using frames. Were you to simply link to the other html page(i.e About page) then the address bar would update.
When debugging an HTTP client, one of your first tests is likely to be a Google search, which lets you see whether your client does non-SSL GETs properly. Everyone knows where it is, everyone can use it, and everyone can see whether it succeeded.
My client has a problem with HTTPS POST. I can reproduce it locally with my specially set-up HTTPS server, but I want others to be able to try it as well. Is there a public web page using HTTPS where sending a test POST is not a bad idea?
Edit: In the end, the problem turned out to be that my client would cache network output by the line when sending over TLS. Obviously, that causes problems for POST but not for GET...
I stumbled across this question while looking for the same thing, but I also found https://posttestserver.com/, which provides such a service for HTTP and HTTPS.
Google App Engine has supported HTTPS for a while now. That should give you a simple, easy way to put up test pages for anybody to see and serve them up over HTTP and HTTPS. Give us the link too, could be useful to use for our clients if the tests are generic enough.
The simplest public HTTPS post test I can think of would be webmail.
For example create a dummy Google account, then take the username and password of that dummy and see if the user can login using https://www.google.com/accounts/ManageAccount (a simple HTTPS post form).
Create a twitter account. Because of the json api, checking for a valid post to twitter is very simple. For the POST, you can look at the API docs for Status Updates. Once you've made a post, you can check the results at the User Timeline.
The API docs even have simple examples with curl to show you how easy it is. The POST:
curl -u user:password -d "status=testing my HTTP POST request" https://twitter.com/statuses/update.json
And getting the status to check it:
curl https://twitter.com/statuses/user_timeline.json?screen_name=user
Any login form should do.
In short, no. But without further info as to what specific bug you're experiencing, it's hard to search for something that already exists. My suggestion would be to find a free hosting service, and put the test page up there, along with a small google ad for some revenue.
Interesting concept, though, the publicly available test cases for standards. I like.
I'll bet that google search will accept a search paramter as POST if you sent it that way.
SSL adds a lot of complexity to the transaction, and you actually should break it up into two pieces.
You should do an GET w/ HTTPS first. When I was smoke testing networking for Netscape/AOL/Mozilla, I used http://www.verisign.com, because that was the home page for the main certificate vendor. I did not test the HTTP/SSL implementation itself, but we figured that while we are sitting around clicking on links in a build, we may as well do some SSL versions of the HTTP requests.
I cannot easily think of a good https: URL that uses POST, but I actually think it matters a lot less.
Once you know that SSL is working w/ HTTP at all, failures that are request-specific are going to be pretty limited, based on my recollection. Then again, this area was not assigned directly to me, so take that with a grain of salt.
My more recent thinking about testing is that test groups need to setup their systems, especially test servers. You would probably get better mileage by getting a good working set of instructions on how to configure HTTPS w/ a self signed certs, and then create your own internal POST test pages.