We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.

Bug 4146

Summary: problem using SSL with paymethods and registration options
Product: OCS Reporter: Juan Pablo Alperin <juan>
Component: GeneralAssignee: PKP Support <pkp-support>
Status: REOPENED ---    
Severity: enhancement CC: alec, kritikes.spoudes
Priority: P5    
Version: 3.x   
Hardware: PC   
OS: Mac OS X 10.3   
Version Reported In: Also Affects:
Attachments: a display of the error

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.