Hi

I'm working on a shopping cart application and for the first time I'm
planning on using Sessions rather than a temporary table to store the
items. My problem is connected with the fact that the callback page
apparently runs on the Secpay server rather than my website. (Frankly
I don't really understand how this works, because I'm still able to
perform database operations and include() files with relative paths).

However, any attempt to access or session data fails
completely. It's not that I need to access the data (I'll already
have it stored in the DB) as much as I'd really like to delete the
Session and the destroy the session file, to avoid problems
with users clicking 'refresh', or the 'back' button, etc. Now, I've
figured out I could get straight back to my own server by writing the
callback page like this:

<form name=form1 method=post action="<? echo $location ?>">
<?
foreach ($_POST as $key=>$value)
{
?>
<input type=hidden name="<? echo $key ?>" value="<? echo $value ?>">
<?
}
?>
</form>
<script language=javascript>document.form1.submit()</script>

But I have a nasty feeling that there is some very good reason for
Secpay running the callback script in their own environment, and that
this would be undermining the security of the operation in some way
that I don't understand.

Can anyone advise me on this?

Thanks.

Captain Nemo wrote:
> Hi
>
> I'm working on a shopping cart application and for the first time I'm
> planning on using Sessions rather than a temporary table to store the
> items. My problem is connected with the fact that the callback page
> apparently runs on the Secpay server rather than my website. (Frankly
> I don't really understand how this works, because I'm still able to
> perform database operations and include() files with relative paths).
>
> However, any attempt to access or session data fails
> completely. It's not that I need to access the data (I'll already
> have it stored in the DB) as much as I'd really like to delete the
> Session and the destroy the session file, to avoid problems
> with users clicking 'refresh', or the 'back' button, etc. Now, I've
> figured out I could get straight back to my own server by writing the
> callback page like this:
>
> <form name=form1 method=post action="<? echo $location ?>">
> <?
> foreach ($_POST as $key=>$value)
> {
> ?>
> <input type=hidden name="<? echo $key ?>" value="<? echo $value ?>">
> <?
> }
> ?>
> </form>
> <script language=javascript>document.form1.submit()</script>
>
> But I have a nasty feeling that there is some very good reason for
> Secpay running the callback script in their own environment, and that
> this would be undermining the security of the operation in some way
> that I don't understand.
>
> Can anyone advise me on this?
>
> Thanks.
>
>

I'm not sure what you're trying to do. But if you're trying to access
or session info (session id's are kept in by default)
from secpay, you can't do it.

Otherwise, if you're using sessions, ensure the call to session_start()
is before *any* output (even whitespace) on every page requiring session
data access.

And don't worry about clearing the session file - just clear the
applicable keys in the $_SESSION array.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================