Bug 4146 - problem using SSL with paymethods and registration options
problem using SSL with paymethods and registration options
Status: REOPENED
Product: OCS
Classification: Unclassified
Component: General
3.x
PC Mac OS X 10.3
: P5 enhancement
Assigned To: PKP Support
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-24 07:58 PDT by Juan Pablo Alperin
Modified: 2012-09-24 10:51 PDT (History)
2 users (show)

See Also:
Version Reported In:
Also Affects:


Attachments
a display of the error (64.85 KB, image/png)
2009-03-24 10:58 PDT, Juan Pablo Alperin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Juan Pablo Alperin 2009-03-24 07:58:27 PDT
If SSL is not enabled site-wide, a problem arises when redirected to use HTTPS for registration payment.  After selecting the registration type, the registration option form expects a registration type to be POSTed.  

On the initial arrival at the registration options selection form, everything appears fine, but on submitting that form (regardless of options selected) the form fails validation.

The problem arises that on submitting the registration options form, users are redirected to HTTPS (paymethod plugins form tend to have to be HTTPS) and so the POST form validation fails and the registrationType variable is not among the submitted variables.  This causes the registration options form to be displayed again, but with no valid registration type.

Hope that made sense.

Current workaround: enable mandatory SSL site-wide.
Comment 1 Alec Smecher 2009-03-24 08:19:32 PDT

*** This bug has been marked as a duplicate of bug 3146 ***
Comment 2 Juan Pablo Alperin 2009-03-24 10:58:59 PDT
Created attachment 1607 [details]
a display of the error
Comment 3 Juan Pablo Alperin 2009-03-24 21:40:38 PDT
Bug #3146 does not take care of this issue.  This is a separate issue related to how registration options are set up in the SchedConfHandler and the way in which the displayPaymentForm method is called. 

The fix probably involves breaking up the registration login into 3 separate URL's instead of two (currently one goes from /registration to /register and then /register again.  We could probably have this go /registration -> /registrationOptions -> /register with this final step finally displaying the registration form (once the registration and a registration_id can be passed in the URL.  

This is just off the top of my head, i'm sure other solutions are possible and may be preferred.
Comment 4 Alec Smecher 2009-03-24 21:42:58 PDT
Thanks, Juan -- I plead jet-lag.