|
|
Posted by Steve Lefevre on 09/21/05 23:42
Chris Shiflett wrote:
> Steve Lefevre wrote:
>
>> I have a php site on a production server. The production server doesn't
>> have the spell libraries, and rather than migrate the site, we setup
>> spell checking functions on the development site, and shuttled the users
>> back and forth with specially crafted get links and forms.
>
>
> This sounds ugly, and you're leaving out some important details. My
> first question is whether the domain name of the development (well,
> not anymore) server is a subdomain of the production server.
No, it's not. They're totally separate machines at different ISPs.
>
>> The POST form or GET link on the production site contains the string to
>> be spellchecked. Once the user is at the development site, the string is
>> spellcheck, and corrected if necessary. The development site checks the
>> http referrer to make sure it's not just anybody, and the only thing it
>> does is spell checking, anyway.
>
>
> Checking Referer is useless, because everyone knows what you expect it
> to be.
I'm not following you. How would anyone know what it should be? Do you
know what it should be?
>
>> After the spell checking is done, we then create links that bring the
>> user back to the development site. On the development site, I have an
>> include at the beginning of each page that checks for a session, and
>> either takes them to the proper page, or throws an error if they are
>> not on the login page and have no session.
>
>
> This sounds confusing, but I think it's because you meant to say
> production instead of development. Did you?
Yes, you are right. Here is the proper paragraph:
After the spell checking is done, we then create links that bring the
user back to the production site. On the production site, I have an
include at the beginning of each page that checks for a session, and
either takes them to the proper page, or throws an error if they are not
on the login page and have no session.
>
>> Most of the time, no problem. When a user is returning from the
>> production site, their session is still set when they load the page
>> on the production server, and they get the appropriate page. However,
>> for a few users, they are somehow losing session data, and they get
>> the error when they try to return from the development server.
>
>
> Maybe their session is timing out? You're sending them to a different
> site, after all.
That could be, but it consistently affects only one user on her home
computer, but not on her work. If the session was timing out, I would
expect it to affect all users, who probably would report it as 'random'
-- they may not make the connection between how long it takes them to
complete the spell checking.
>
> I think we acn help more if you offer some details, such as how you're
> handling sessions. It also sounds like you could avoid all of this
> confusion by simply having your production server communicate directly
> with your development server. Using the user as a data transport seems
> very ugly.
>
> (Also, you didn't mention how cross-site scripting fits in.)
I'm handling sessions by having an include at the beginning of each page
on the production site do the following:
- session_start();
- check for certain session variables
- if the variables exist, display page appropriately,
- else show a blank page.
There is one special page, the login page, where they enter the username
and password, and if they are correct, that page sets the session
variables and re-directs the user.
Is the above what you are asking for?
I guess I'm confused about what cross-site scripting is; what I was
referring to was having a form on a page in the production site actually
submit the information to a page on the production site. Users aren't
aware they are traversing sites because this happens within a frame.
>
> Hope that helps.
>
> Chris
>
Thanks, Chris.
Navigation:
[Reply to this message]
|