2 Replies Latest reply on Aug 29, 2014 10:06 AM by PalmDBS

    Base Elements HTTP_Post for PHP Login


      I'm not a PHP guy, but I've been doing a number of HTTP_Post calls with the Base Elements plugin to return a web page or other information from servers in the cloud. This works great when I know the format of what to post, including the headers.


      I have a client with a web page that has a PHP login. I can read the PHP and see it is doing a post to login. Knowing the PHP code, is there a way to format an HTTP_Post URL to automaticaly log into this web page using User IDs and passwords stored in FileMaker?

        • 1. Re: Base Elements HTTP_Post for PHP Login

          Hello Taylor,


          Given all of the PHP code (plus any login-related Javascript that it writes to the page), you should have the information necessary to reverse engineer the login process, and then successfully simulate it using the BE plugin (assuming that no Captcha step is involved).



          That said:


          Sometimes the easiest way to reverse engineer these things is via careful analysis of each response that the server returns to the browser, i.e. the HTML and any http response headers.



          In the easiest scenario:


          One only needs to examine the form and input elements within the HTML.  Using the names of the form elements, and knowing the proper values to supply, one can use the BE plugin to send HTTP request content to the server which simulates the user logging in.





          If the HTML contained the following form:


          <form action="http://myserver.com/some/url.php" method="post">

          <input type="text" name="user_name"/>


          <input type="password" name="secret_password"/>


          <input type="submit" name="submit" value="Submit"/>





          Then the http request content that you would send via the BE plugin would be:






             MY_USERNAME is replaced with the url-encoded username value


               - and -


             MY_PASSWORD is replaced with the url-encoded password value



          The above request would be sent via http post to the action url  ( in this example:  http://myserver.com/some/url.php ).






          Some advanced considerations:


          1)  Oftentimes http cookies are being passed back and forth (between the server and the browser).  This is done via http headers.  You will want to make sure to properly capture and send any needed cookie values.


          Reference for HTTP cookies:  http://en.wikipedia.org/wiki/HTTP_cookie



          2)  Login processes can sometimes be a sequence of multiple client/server exchanges.  These sequences can be invisible to the general browser user, because they are driven by redirect commands sent by the server of which the user is generally unaware.  If the server returns a status of 302 "found", as a response to your http request, just keep in mind that this probably means that the server is redirecting you to a new url (specified in a header).



          3)  It is possible that some Javascript could be running on the client side, which adds/removes/sets some values which are to be posted back to the server.  The purpose of this could be simply to provide the server with additional client environment information during the login process, or to help prevent automated logins, or it could just be the nature of how the page is being rendered, e.g. in a more modern single page application approach.  I would start off by assuming that you don't have to deal with this, but keep it in mind if you are up against something which seems to defy your expectations.  In such a case, you would need to grok the Javascript enough to determine what tweaking of your request values you must do before you send your request.




          Lastly -- A caution:


          All of the effort put into this sort of endeavor can be lost and the system can suddenly break if there comes a time when whoever maintains the target web page updates/modifies their server code.  As I believe you know, the safest approach is to see if there is a maintained API that you could use to meet your needs -- something that you can rely upon to be consistent in terms of the interface.



          HTH & Best,


          - steve




          Message was edited by: steve_ssh


          ( Edited message to try to better answer the question/concern. )

          • 2. Re: Base Elements HTTP_Post for PHP Login

            ^ +1 


            Definitely walk through the process manually, watching all headers back and forth (I use the "Live HTTP headers" plugin on FF), then replicale the steps with the plugin.  Simple things like not passing the referrer can break your automation attempts if the server checks against that.  As stated above, you cannot simply reply on the addresses you see in the URL bar, as there are often calls to javascripts that set cookies/timestamps, etc, that need to be replicated. 


            In general, I tend to replicate every call and get it working, then try to cut out unneccesary calls to images, etc (I've seen calls to images that are redirected to scripts that set cookies then return the image) one at a time.