January 11th, 2004, 07:03 PM
non-SSL -> SSL page variable transfer? + your CF webhost?
I'd like to use CF to make my own shopping cart - I thought about storing ordered product information in sessions (order page is regular, http page) but I'd like to know if that sessions will be readable on the SSL, checkout (https) page?
Can you suggest me solution if all sessions are erased when entering SSL certificated page? I MUST have final, checkout page under https and I must find a way to transfer some variables on it.
Also, I'd like to know where do you host your CF sites and for how much money - I don't want to post this question in hosting forum because I don't want to hear anything from service sellers - I want to hear user suggestion. Looking forward to hear your comments.
January 12th, 2004, 09:45 AM
Sessions are independent of protocol. They work the same under http or https becuase the session identifier is a token that is stored in a cookie on the user's machine (or passed manually on each page request but a cookie is the default behavior). You'll have no problem reading the session data on an https page.
January 13th, 2004, 09:50 AM
thanks kiteless I will try via sessions, can you please suggest me some stable but cheap CF webhosts?
January 13th, 2004, 10:58 AM
I use Crystaltech, which runs about $16 a month for CFMX 6.1 shared hosting I belive.
January 13th, 2004, 12:46 PM
are they stable webhost?
does anyone know some, a bit cheaper webhost to suggest? (of course CF support is a must)
January 15th, 2004, 10:56 AM
We offer CFMX 6.1 hosting from $6.99/month. That comes with MS SQL 2000
January 15th, 2004, 11:31 AM
Jodo: what about Access db support? I sent email to your support/sales team yesterday and never recieved any reply
January 15th, 2004, 11:36 AM
I'm not sure we got your email. We answer most sales emails within a few hours. What's your ticket ID?
Yes, of course we support MS Access.
January 15th, 2004, 11:37 AM
@kiteless: I heard that sessions are blanked when you try to transfer it to the SHARED https page because of domain changing when accessing shared SSL - is that true? I must have my own certificate in order to use sessions? If so, is there any cheaper solution than InstantSSL.com you can suggest?
Also, I need to crypt credit card # because i MUST have it emailed - how perfect is this:
<cfset variable = "#form.cc#">
<cfset encrypted = "#encrypt(variable, "aljksflkajsfgnasoughuhsaiotu9382y5y1935y91y395y812395ryh9hasrhusjklbfkalf23g29523rgfalsjbfjasbf973g rfasb")#">
Decypted: #decrypt(encrypted, "aljksflkajsfgnasoughuhsaiotu9382y5y1935y91y395y812395ryh9hasrhusjklbfkalf23g29523rgfalsjbfjasbf973g rfasb")# </p>
Can you suggest me something better in order to save CC# from email spiders or you think this one should be enough?
January 15th, 2004, 11:39 AM
I didn't recieve any id. I sent email
and that's it - nobody answered
Can you also answer to my question in regards to shared/non-shared SSL certificates, please? You offer shared one, right?
January 15th, 2004, 11:57 AM
Ok, I pulled this ticket up from the answered section. It appears the system couldn't get the response through to you. That's why you probably didn't receive a confirmation email with your ticket id.
We offer shared SSL for free. You need a dedicated IP for each domain you want shared SSL enabled on. One dedicated IP is included for free
January 15th, 2004, 12:12 PM
Can you answer to all question I sent you in email? If needed, I will resend it, just give me some address where you will be able to recieve/reply to it.
January 15th, 2004, 12:16 PM
Just resend the email from a different email address
January 15th, 2004, 12:23 PM
January 15th, 2004, 01:16 PM
Regarding sending a credit card number in an email, I would strongly recommend against it. If you can decrypt the card number, then someone else can to. Keep in mind that you could probably be sued if a card number was compromised in this fashion. I can't think of any reason why you would need to keep the number...you use it during the transaction, store the resulting status codes from the processor, and that's it. There's no reason I've found to justify storing the card number. Places like Amazon.com are unique in that they have entire departments that do *nothing* but ensure the security of their networks and databases. If you can't provide similar expertise, then don't store that card number in a database, email or anywhere else.