All geek questions in one place

Log in to the remote site via iframe

OK, so what I need to do is the ability to set the login screen from the remote site in the iframe, and when they click on the login button, it will log in to the remote site and then change the local page to page 2 that’s what I managed to do still that very little. and if this is not possible, can I create a local login that passed the information to the remote site and receives a cookie, and then loads the next local page?

<html> <head> <title> </title> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" > <style type="text/css"> #outerdiv { width:400px; height:360px; overflow:hidden; position:relative; } #inneriframe { position:absolute; top:-125px; left:-802px; width:2000px; height:2000px; } </style> </head> <body> <div id='outerdiv'> <iframe src="http://www.99designs.com/login" name="myiframe" id='inneriframe' scrolling=yes></iframe> </div> </body> </html>
+4
source share
1 answer

Most likely impossible ...

Most likely, this will not be possible because the hosts between your local and remote will be different, so JavaScript will not allow you to access the contents of the iframe due to the Same origin policy that all browsers use.

http://en.wikipedia.org/wiki/Same_origin_policy

The only way to achieve this is if the other site does not use XSS protection and allows you to directly receive / send the login URL to your site. It really depends on who controls that ... if you own and control a local and remote site, then it will be possible. If this is not the case, it is unlikely and will be subject to various possible problems (i.e., if the remote site changes the way the login system works, the system will be broken, or it will not be possible to obtain fine-grained control over the login process, so you won’t be able to implement your own error handling).

I assume that I say you should not rely on the XSS vulnerability.

Why is this protection protected from?

If you think about it, if there was no truth above, then there would be many very strong and scary things that evil people could do in the background while you were surfing the site. For example, if you could use JavaScript to exchange data between nodes in a hidden iframe, there would be nothing to stop someone encoding a hidden script that went to facebook, relied on your browser, saved your username and password, entered system, and then started publishing / deleting / making friends ... (and this is just a mild example that does not include credit card details or government sites)

Other options?

It is best to implement something in this direction - use a server-side scripting language, such as php, asp, java, node.js, ruby, lisp, perl or python. Scripting languages ​​do not have restrictions on working with external resources. Again, as long as the external site supports a simple or open login system, you should be able to mount something together, and not allow your JavaScript to register using the server side of the script as a proxy through AJAX. For example, you can use cURL via PHP to send to an external site and receive the cookies that it returns. However, this is not an easy project, and it will take a lot of work to work without problems.

+5
source

Source: https://habr.com/ru/post/1433434/

More articles:


All Articles