I've registered domain.com at Loopia and use their "redirect", which actually opens a website in a frame - in this case mysite.com/domain. However, if I visit mysite.com/domain I want to get redirected to domain.com.
Is this possible, and how would it affect search engines?
Thank you in advance.
You can park your domain instead of redirect it or open your website in a iframe.
When you park your domain, actually your new domain contains all data(s) in previous domain and I think this is a better method.
Furthermore, you don't loose any page rank or SEO ranks.
Related
I have this question: is safe use an iframe to load the page where the customer will do the payment. For example paypal or DineroMail or the page that does the credit card payment.
Because My boss wants that the customer feels that never leaves the site so in my site I added an iframe (and inside this I load the url of the payment) but don't know if is correct and safe or no.
Thanks.
From a technical security point of view (Same Origin Policy), it is exactly as safe to open an iframe as it is to open a new tab.
From a UI point of view, opening an iframe in certain locations can deceive the user and you might be accused of trying to clickjack the user into making an inadvertent payment if you are not careful.
I cannot say anything about PayPal's own policy, but you should make sure they are okay with it.
I have been through this several times with many clients. A lot of it has to do with 1)he isnt comfortable with a customer leaving his site in fear the checkout wont occour or 2) its a pride thing that he wants clients to feel all the services can be performed in site.
One of the things that your boss needs to understand is that people like using paypal because they are trusted and its a familiar process to them. He needs to know that not only are people ok with being redirected to paypal, but they expect it. If I where to run into a site where they checked me out in an iFrame on paypal it would be a red flag for me. Why? Because with the redirect I can see the address bar. I know that Im at paypals site and I can see if its a secure connection.
If he is dead set on a customer never leaving a site. He needs to do something like paypal payments pro. This is probably the solution he really wants.
EDIT
I found your answer answer when dealing with the same issue myself last weekend and wanted to come back with something better!
Its called flex and its apart of the adaptive payments classic api. Which will take an additional application process which your boss may fee is well worth it.
https://developer.paypal.com/docs/classic/adaptive-payments/integration-guide/APIntro/
Head about 3/4 of the way down and youll see step by step instructions to do exactly what your loooking for. A secure paypal iframe.
Quick tip: If you have to incorporate it in your own processes simply do the following.
1) obtain your paykey after sending the request to paypal.
2) call in the javascript source as in the tutorial.
3) redirect the window manually as opposed to their created paypal button. aka https://www.paypal.com/webapps/adaptivepayment/flow/pay?paykey=YOURPAYKEY
another good source is : https://www.paypalobjects.com/webstatic/en_US/developer/docs/pdf/pp_adaptivepaymentsmobile.pdf
It is safe if Paypal allow it, but you have to be careful from a UI point of view.
If your site is loaded over http and you load the IFrame within your site, it appears to the user not to be secure even though the IFrame is loaded over https. This approach is also vulnerable to a MiTM attack as an attacker could intercept and change the IFrame URL to something like http://www.evil.com and nobody would be the wiser at the time of entering the card details.
If your site is loaded over https your customer has to trust you with their card details as they cannot be sure that the IFrame is actually pointing to the Paypal domain on https (https://www.paypal.com) and not your site. Yes they could right click and check the source, but this is a step too far for most users and technically an evil site could swap the IFrame for an evil version without the customer noticing.
My recommendation is to actually redirect to https://www.paypal.com because then it is shown in the address bar with a padlock and reassures users that they are giving their details to Paypal and nobody else.
I want something between a URL frame and URL redirect.
I have a domain called http://www.mydomain.com.
I have pages on my site. When I click on "page1.html", I would like the address bar of my browser to show "http://www.mydomain.com/page1.html". I want it to show this because then users can click "back" or "forward" in their browsers.
Right now, my domain name provider (Namecheap) has two choices:
URL Frame: This always shows "http://www.mydomain.com", which messes up "back" and "forward" because the subpages aren't shown.
URL Redirect: This causes the address bar to show "http://www.uglydomain.com/subfolder/subsubfolder/page1.html".
What is the best solution? A silly, slightly incomplete solution would be to hard-code all of my links on my pages to "http://www.mydomain.com/page1.html". Can I achieve what I want through .htaccess, redirect rules, or something else?
In theory, if you had access to the site hosting the frame document, you could implement something with pushState and postMessage, but its highly unlikely that you do.
The only real solution is to get proper DNS hosting and point the DNS for the domain at the server hosting your website, and to have sufficiently good hosting that you can set up a virtual name host for the domain on your web server.
I need to add context or the current state of my website to the URL of the page.. So that if a user copies and sends the URL to another user. The other user can see the exact state of the website that the sender was watching, i.e. the tab he was in,and the data he was viewing. I have seen similar things being implemented in other websites like facebook, gmail, etc but I don't know how to do that in my application. How should I approach this problem?
Use pushState and friends to modify the URL to one which your server can use to deliver a page that starts in the desired state.
If I put a rel="nofollow" will the referrer site will appear on Google Analytics of example.com?
Example:
Referrer site is: referrer.com
nofollow is intended to prevent the bot from going TO the site in the link (or any link if it's in a meta tag).
ie: Site-A has a link:
<a rel="nofollow" href="//site-b.com">Site-B</a>
That nofollow is meant to tell Google that it shouldn't consider the two sites to be linked together.
Or two pages, or whatever.
<meta name="robots" content="noindex">
Tells Google that it shouldn't index THIS page in its search.
In your case, you're looking for a way to remove the JavaScript:document.referrer from Site-B. You can't do that from Site-A. When a user clicks from Site-A to Site-B, once they're on Site-B (where GA is installed), there's nothing that you can do from Site-A to prevent it.
There's no way to do that, without sending a user to your own server, and manually redirecting to/from elsewhere, using apache, or using some other server-side solution... Even then, the referral will come from somewhere -- it's just a case of where that somewhere, is.
HOWEVER if you're talking about two sites that YOU OWN and you're trying to exclude Site-A from Site-B's reporting, there are ways of doing that from within the GA control panel. You can add filters on the traffic to exclude IPs or domains.
Or, if you control the GA tracking codes on Site-B, you can do:
_gaq.push(["_addIgnoredRef", "Site-A.com"]);
If, however, you're working for Company-A, and you don't want people in Company-B to see your site in their report... ...that's where it can't be done without serious server-side header-manipulation.
No Change
clicking a link with rel="nofollow" will still send the current page as the referer.
A User browsing is not influenced by rel="nofollow"
nofollow applies to bots (site crawlers), google analytics tracks users (who are not bots). As such the nofollow on a link will have no effect on google analytics statistics - because it doesn't modify real-user activity.
Yes, it will appear as a referer. Nofollow tells robots not to follow this link and doesn't affect clients browser behaviour in any way.
http://en.wikipedia.org/wiki/Nofollow
I'm maintaining an application that goes sort of like this:
There is a Page A with a Frame that shows Page B. Now page B is part of a completely different product in a separate domain.
Now, they want that when an option in B is clicked, the WHOLE page is redirected to another page in A. The problem is that the url of A is something like www.client.A.com/Order/Details/123, and when we click in be it should redirect to something like www.client.A.com/Order/Edit/123 but B doesn't know anything about A. It doesn't know which order # is currently selected or anything about A. Page A who has the frame B does know it.
For now my solution has been to just redirect to the AllOrders so something like client.MyCompany/Orders
but since B doesn't know which client is calling it (its a multi-tenant app), I'll add it in the webconfig. (so each client has its own webconfig with a different value).
I dont find this solution optimal but I can't think of anything else! I already tried putting the needed url in page A in a hidden Div (since A does know all the info) and then trying to read the whole DOM of the page from B to find it.... unfortunately I can only get access to Frame B's DOM... (I tried with jquery).
I know frames are evil, but this is how it is written... any ideas?
Thanks!
If the parent page A and the iframe page B are in different domains, you will not be able to access methods or fields via B's parent property, nor will script in A be able to reach into B's content, nor will you be able to share global variables between A and B. This boundary placed between page A and page B is a key part of the browser security model. It's what prevents evil.com from wrapping your online bank web page and stealing your account info just by reading the internal variables of the javascript of the bank's web page.
If you have the luxury of requiring the latest generation of browsers, you can use the postmessage technique mentioned in one of the other answers here. If you need to support older browsers, you may be able to pass small amounts of information using cross-domain client scripting techniques in the browser. One example of this is to use iframes to communicate info between the outer page A and the inner page B. It's not easy and there are many steps involved, but it can be done. I wrote an article on this awhile ago.
You will not be able to monitor clicks in B's iframe from the parent page A. That's a violation of browser security policies at multiple levels. (Click hijacking, for one) You won't be able to see when B's URL changes - A can write to the iframe.src property to change the URL, but once the iframe.src points to a different domain than A's domain, A can no longer read the iframe.src property.
If A and B are in different subdomains of the same root domain, you may have an opportunity to "lower" the domain to a common root. For example, if the outer page A is hosted in subdomain A.foo.bar.com, and B is hosted in subdomain foo.bar.com, then you can lower the domain in page A to foo.bar.com (by assigning window.domain = "foo.bar.com" in A's script). Page A will then behave as a peer of page B and the two can then access each other's data as needed, even though A is technically being served from a different domain than B. I wrote an article on domain lowering, too.
Domain lowering can only peel off innermost subdomains to operate in the context of a root domain. You can't change A.foo.bar.com to abc.com.
There is also a slight risk in lowering domains to a common root domain. When you operate your page in its own subdomain, your html and script are segregated from the other subdomains off the common root domain. If a server in one of the other subdomains is compromised, it doesn't really affect your html page.
If you lower your page's domain to the common root domain, you are exposing your internals to script running on the common root domain and to script from other subdomains that has also lowered its domain to the common root. If a server in one of the other subdomains is compromised, it will have access to your script's internals and therefore it may have compromised your subdomain as well.
in case the page & frame are not on the same domain, you'll have to use postmessage as the same-domain policy prohibits normal javascript-communication between pages/frames of different domains because of security concerns.
postmessage is part of html5 and works in all modern browsers (including IE8). if you need support for older browsers (specifally IE6/7), you could use the jQuery postmessage plugin (which transparently falls back to some nice hash-tag trickery for older browsers).
and as a sidenote: not sure if frames are evil, there are some problems (usability, SEO, ...) related to them, but i did some research and most of these can be tackled i think.
If you want to communicate between frames in javascript you can use 'parent':
If frame A has a variable value, eg:
var orderNo = 2;
For frame B to read it it would refer to
var frameA_orderNo = parent.frames[0].orderNo;
(assuming that frame A is the first frame declared)
So you can set up global variables within each frame that the other frame can read and therefore you can get the order # in old fashioned javascript (never tried it in jquery).
Wow frames - never thought I'd think about them again.