-
Notifications
You must be signed in to change notification settings - Fork 1
/
webwarning.htm
9 lines (9 loc) · 3.5 KB
/
webwarning.htm
1
2
3
4
5
6
7
8
9
<h1>Instagram-API Warning!</h1>
<h2>Can I run this library via a website?</h2>
<p>No. Don't do it. You cannot <em>safely</em> use this <em><strong>or any other</strong> 3rd party Instagram libraries</em> directly via a website!</p>
<p>This library (and <em>all other</em> 3rd party reverse engineered Instagram libraries), is made for command line usage in a terminal by running the script like a program (such as <code>php yourscript.php</code>). We do <strong>not</strong> recommend running this library via a web browser! Because browsers will terminate the PHP process as soon as the user closes their connection to the page (closes the tab, or presses "Stop loading page"), which means that your script can terminate at any moment. This library is not a webpage! It is an Instagram for Android application emulator. It emulates an <strong>application</strong>. Not a webpage. You cannot just randomly kill this library in the middle of work! (You might kill it while it's writing to disk or calling some important APIs!)</p>
<p>And furthermore, if it's used on a webpage then it must waste time logging in to Instagram every time the user refreshes the webpage, since each page load would start a new script (meaning "a new Instagram app emulator") from scratch. And there are also massive risks about concurrent access from multiple web requests to a single user account which can corrupt your settings-storage or cookies. So we really, <em>really</em> do not recommend running this library via a browser! It's a <em>very</em> bad idea!</p>
<p>Instead, you should run your Instagram app emulator script as a permanent 24/7 process, and make it dump data to a database which your regular website reads from, or make some kind of permanent localhost daemon that can listen locally on the server and receive queries on a port (localhost queries from the main website's scripts), and then performing those queries via the API and responding to the website script with something like JSON or with serialized <code>src/Response/</code> objects, which the website script then transforms for final display to the user.</p>
<p>You must also be sure that your permanent process periodically calls <code>login()</code> inside your 24/7 PHP process, to emulate the Instagram for Android application being closed/opened and refreshing itself (like a real user would do). Otherwise it will soon get banned or silently limited as a "detected bot" by Instagram due to never calling login. Preferably use the same refresh ranges we use by default, so that you refresh <code>login()</code> within a random range between every 30 minutes, or at max every 6 hours.</p>
<p>So, to recap: Make your "Instagram application" part a permanent process, and then make your webpage interact with that permanent process or an intermediary database in some way. That's the <em>proper</em> architecture system if you want to use this library online! Imagine it like your website talking to a phone and telling its permanently running Instagram app to do things. <em>That's</em> the proper design and that's how you have to think about things.</p>
<p>Never forget this fact: This library (and <em>all</em> other 3rd party libraries) is an Android application emulator. It is not a website and will <em>never</em> be able to become a website (because the Android application is not a website!). Therefore, we will <em>never</em> give support to anyone who decides to use the library directly inside a webpage. If you do that, it's <em>at your own risk</em>! It is a really terrible and unsupported idea!</p>