MachForm Community Forums » MachForm 2

1. sonic
   Member

   Hi
   Is it possible to send the login data via URL?
   I have tried this here:

   http://yoururl.com/machform/index.php?ADMIN_USER=admin&ADMIN_PASSWORD=12345

   Unfortunately it will not work.

   Regards
   Sonic

   Posted 16 years ago #
2. 

   redityo

   Hi ..

   For security reason I think it's not possible to parse the login data from url :) anyway may I know why do you want to do that ?

   ---

   MachForm Support

   Posted 16 years ago #

3. sonic
   Member

   Hi

   I would like an automatic access without login procedure. The security reason is no problem, we use this form in an intranet.

   Posted 16 years ago #
4. 

   redityo

   I see .. You can edit your index.php on machform folder and add this line around line 11 below session_start() code :

   $_POST=$_GET;

   after that you can call your machform login using this url

   http://host.com/machform/index.php?admin_username=admin&admin_password=admin&submit=1

   ---

   MachForm Support

   Posted 16 years ago #

5. sonic
   Member

   Hi

   I have tried it and it works fine.
   Thanks

   Posted 16 years ago #

6. Robye
   Member

   and what about reach via URL the export_entries.php

   im trying to give direct access via URL, esemple:

   http://mysite.com/machform/export_entries.php?id=4&type=csv&admin_username=123&admin_password=123

   its possible do that?

   Posted 15 years ago #
7. 

   redityo

   Hi,

   If you need to export an excel/csv file without login to machform admin, you can by pass the session check. To do so, simple remove this line from "export_entries.php" file.

   require('includes/check-session.php');

   I think it's better for your security reason

   ---

   MachForm Support

   Posted 15 years ago #

8. Robye
   Member

   yes , probably its true because leave "unprotected" just the export_entries.php file

   Posted 15 years ago #

9. ventilator
   Member

   It is a security problem to attach your usernames and passwords to a URL even on an intranet.

   Think about it:

   Unless you turn off the referral function of the client's browser, if they navigate away from your intranet page the URL and the login data will be in the log of the external web servers they go to because the login data is at the end of the URL.

   In short, should those user credentials match any other credentials, a third party now has your passwords and usernames with a single click of a button by your users who will very likely be blissfully unaware of what they just did.

   There is a common trick used by people that make money off of referral links called double meta refresh. The goal being to push you to another, completely neutral page and URL and then if you're browser reflects that new clean URL refer you to the destination page. This is used to break the referral process and obscure the destination page from seeing too much information about the last page the user came from.

   Something similar can be done with a neutral exit page or Javascript. You use JavaScript to force them to exit via that page. Even if you call to the page with arguments in the URL, you detect that with JavaScript and do not allow them to exit until they load the page with a URL that contains no additional data or you simply push them to the neutral exit page whether they like it or not.

   You can also obscure this data like the default install of MachForms does. Basically if you look at the URLs used in the system, very little data of any obvious intent is transmitted in the URLs. You could roll your own login system that transmits the more personal data by referencing unique numeric IDs or cookies and linking to data in a MySQL database.

   Be careful with cookies, although they should be protected from prying eyes, there are plenty of ways I can read the cookies you set even though I should not be able to.

   Another option which can add even more security is to require your users to use a specific separate web browser to access your intranet. There are versions of FireFox that are designed to be self contained. These versions are usually used with flash storage but they basically stand alone as programs.

   You would install the browser.
   Set it up with the security settings you like (about:config), etc.
   Install whatever certificates or authorities you may want.
   Make the home page of the browser your intranet's top page.
   Copy the browser install directory (natively or compressed) to your server.
   Distribute the browser with a script, or manually.
   Put a link on their desktop to start this separate browser with a script, or manually.
   Rig your intranet to deny access unless this internal browser is used.

   This last option offers lots of options. You can be sure JavaScript is on like that. You can be absolutely sure of the browser they are using like that. You can be sure they aren't transmitting referral information and you can turn that feature off without breaking other sites that often do require it. You can even control the version of the program they are using. If you're handy with Javascript or XUL you can even disable the standard interface for the additional browser and make it look like a stand alone application with whatever controls you like.

   Posted 15 years ago #

RSS feed for this topic

Reply

You must log in to post.