By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,567 Members | 1,056 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,567 IT Pros & Developers. It's quick & easy.

HTTPS & PHP

P: n/a
Hi all,

In mind this is a daft question, but here goes.

My hosts allow secure https logins on specific directories. What I want
to do is have a login screen in flash, if the user enters the correct
username and password I would like to set the HTTPS username and
password using php/flash and then open the secure page.

In my mind at this point they'll be logged in and then can navigate the
secure page without seeing the browsers https login dialog. Am I
kidding myself, or is this possible?

Troot

They're config is the following:
PHP Version 4.3.11
4.9-STABLE FreeBSD
Zend Engine v1.3.0

Apache/1.3.33 (Unix) PHP/4.3.11 mod_ssl/2.8.22 OpenSSL/0.9.7c
FrontPage/5.0.2.2635 mod_throttle/3.1.2

Jul 17 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
*** Troot wrote/escribió (18 May 2005 07:58:50 -0700):
My hosts allow secure https logins on specific directories. What I want
to do is have a login screen in flash, if the user enters the correct
username and password I would like to set the HTTPS username and
password using php/flash and then open the secure page.

In my mind at this point they'll be logged in and then can navigate the
secure page without seeing the browsers https login dialog. Am I
kidding myself, or is this possible?


I know nothing about Flash. What's your doubt about the PHP part?

In any case, there isn't _one_ authentication system out there but lots of
them. You'd need to know the spec of yours.

--
-- Álvaro G. Vicario - Burgos, Spain
-- http://bits.demogracia.com - Mi sitio sobre programación web
-- Don't e-mail me your questions, post them to the group
--
Jul 17 '05 #2

P: n/a
Keep in mind that you'll want your flash animation on a secure page,
not just a plain HTTP intro page. If you don't then you'll be sending
usernames and passwords as plain text, and that's a notable security
hole for a site you want to secure.

I've worked on systems that required server-dialog authentication, and
ones that simply had the site on https, that I've built my site
authentication on top of. From a user-friendliness and flexibility
perspective, I prefer the second technique.

I usually build sites that require fairly flexible/robust role-based
permissions anyway, so with the second technique I start with a clean
slate instead of having to interface with aonther system to track
usernames/passwords/etc. and then extend.

~D

Jul 17 '05 #3

P: n/a
dracolytch wrote:
Keep in mind that you'll want your flash animation on a secure page,
not just a plain HTTP intro page. If you don't then you'll be sending
usernames and passwords as plain text, and that's a notable security
hole for a site you want to secure.
Not true... as long as the flash is communicating with a PHP script that
is itself under SSL, then the communication between them is encrypted.
The same applies for normal HTML forms. If you fill in a form from
http://example.com that posts to https://example.com, then the posted
information that is sent in the request would be encrypted since the
connection itself would be.
I've worked on systems that required server-dialog authentication, and
ones that simply had the site on https, that I've built my site
authentication on top of. From a user-friendliness and flexibility
perspective, I prefer the second technique.
I also prefer to use my own authentication model, it just makes
debugging easier.
I usually build sites that require fairly flexible/robust role-based
permissions anyway, so with the second technique I start with a clean
slate instead of having to interface with aonther system to track
usernames/passwords/etc. and then extend.


Same here.

--
Justin Koivisto - ju****@koivi.com
http://koivi.com
Jul 17 '05 #4

P: n/a
The flash bit doesn't really matter, I'll just use that to post/get
variables to php. I know theres a variable in php called $AUTH_USER_PW
(or something like that). What I'm wondering is if I can do something
like this:

<?php
$_SERVER['PHP_AUTH_USER']=$some_variable_passed_in;
$_SERVER['PHP_AUTH_PW']=$some_other_variable_passed_in;
?>

then redirect the user to the directory (which will be under https://)
and have the username and password already entered for them.

If I do need to give more info, what would I need to know?
All I know about the authentication system is the following:
They're config is the following:
PHP Version 4.3.11
4.9-STABLE FreeBSD
Zend Engine v1.3.0

Apache/1.3.33 (Unix) PHP/4.3.11 mod_ssl/2.8.22 OpenSSL/0.9.7c
FrontPage/5.0.2.2635 mod_throttle/3.1.2

Jul 17 '05 #5

P: n/a
Ack! You are correct. Here we have a secure server and a non-secure
server where the secure server does not accept normal http requests at
all, and I was thinking along those terms. I need to get out more. ;)

~D

Jul 17 '05 #6

P: n/a
Sorry, I'm a little bit confused now, does this mean that my options
are:

1. Take the whole thing into the secure directory, authenticating with
the browser dialog
2. Design and build my secure/authentication model with php, which I
can control the login method on

Does anybody know then how it is somebody can go into a secure site
(such as hotmail, airline tickets etc.) with just a normal login form
in html?

Jul 17 '05 #7

P: n/a
*** Troot wrote/escribió (18 May 2005 10:02:19 -0700):
The flash bit doesn't really matter, I'll just use that to post/get
variables to php. I know theres a variable in php called $AUTH_USER_PW
(or something like that). What I'm wondering is if I can do something
like this:

<?php
$_SERVER['PHP_AUTH_USER']=$some_variable_passed_in;
$_SERVER['PHP_AUTH_PW']=$some_other_variable_passed_in;
?>


Alright, apparently you're using HTTP authentication. This has nothing to
do with HTTPS/SSL, which is merely an encrypted channel for sensitive
information. This is how it works:

1) User asks for a document.
2) Server software checks if credentials are needed.
2.1) If not needed: page is served.
2.2) If needed: server software checks whether credentials were provided
in request headers.
2.2.1) If provided and username+password are valid: page is served
2.2.2) Else "auth required" message is returned to browser

Browsers handle HTTP auth internally: that means that if a browser gets the
"auth required" message it will *always* display a dialog for user enter
them. This is the key point.

Why? Because Apache itself will only create the PHP_AUTH_* variables if
browser sends credentials. And browser only sends credentials if entered in
its built-in dialog. You cannot use a custom HTML form (or Flash form).

Alternatives? You can use your own server software (that's it, a custom PHP
script rather than letting the task to Apache). The only issue is that this
system won't allow you to access anything that's not PHP: images,
stylesheets, PDFs... To make it worse, if the PHP script itself is
protected by Apache then it won't work: browser will always prompt user.

I guess 'maybe' you can share password files between your ISP's system and
yours, but you probably must write your own system to use them.
--
-- Álvaro G. Vicario - Burgos, Spain
-- http://bits.demogracia.com - Mi sitio sobre programación web
-- Don't e-mail me your questions, post them to the group
--
Jul 17 '05 #8

P: n/a
great, thanks Ivaro, I think that clears it up for me. Basically, my
choice are:

1. go all authenticated (php, images etc) which is secure
2. build my own system of authentication with php, which will leave
images etc open, but does provide 'some' protection

Jul 17 '05 #9

P: n/a
This is essentially correct. You need to evaluate the value/risk of
your non-PHP content when you're choosing a method.

Traditional commerce sites tend to go for method 2. For example, here's
the paypal logo, served over a secure connection:
https://www.paypal.com/en_US/i/logo/paypal_logo.gif

In this case, PayPal's valuable data is secured by their custom
authentication system.

Venues selling media such as pictures or audio, on the other hand,
traditionally use method 1, to prevent people from stealing their
media.

You ~can~ use PHP to do things like temporairly retrieve data from
non-servable directories, or pull data out of a database for display.
This can protect your media content fairly well. On the other hand, it
tends to come with additional processing overhead.

~D

Jul 17 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.