Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

At 08 NOV 2002 10:09:13PM Dave Harmacek wrote:

I have a client using IIS 4.0 and OI16 with Web Deployment, that is, oicgi.exe. They want to start to accept credit cards so I have to present a page using SSL. I understand they must get a site certificate, too.

What do I have to do in a custom INET_ procedure so that our transactions are in SSL?

Suprised I found nothing about this in a search on this site.

Dave


At 09 NOV 2002 12:40AM Richard Hunt wrote:

Dave,

I am not sure if I should respond because I am guessing here. I always thought that "SSL" and "site certificates" were like a product you buy for your internet server. And once you install it or have it going, you use the "https:\\" rather than the "http:\\". And that would port it thru port 443 "secure" rather than port 80 "unsecure".

So, again I am guessing, all that is needed is to change the "http:\\" to "https:\\" once you have purchased the "SSL" software and installed it.

And I am very interested in the responses you get on this subject. I always find the internet intentionally confusing. I sure hope I didn't stick my foot in my mouth on this one.


At 09 NOV 2002 01:09AM Donald Bakke wrote:

Dave,

Richard is correct. Simply use "https" rather than "http". All the work is done via the certificate and the server software. Pretty cool, eh?

[email protected]

SRP Computer Solutions, Inc.


At 11 NOV 2002 08:44AM Dave Harmacek wrote:

Hi Don.

I understood that the initial link starts with "https" instead of "http". However, after the first page there are no static pages in my application. All returns are thru INET_customroutine.

Are you saying that the response from the INET_customroutine is automatically returned via "https"? Or, are there any changes to the headers of the html I'm returning? Thanks, Dave </QUOTE> —- === At 13 NOV 2002 12:31PM Donald Bakke wrote: === <QUOTE>Hi Dave, Whenever you are responsible for creating a link you need to put the "https" in the HTML. Dynamic content addresses are controlled by the web service. So, if a valid port and SSL certification are being used then the web service *should* be putting the "https" in place of "http". Does that help? [email protected] SRP Computer Solutions, Inc. </QUOTE> —- === At 14 NOV 2002 05:09AM The Sprezzatura Group wrote: === <QUOTE>Dave, HTTPS is just a protocol that the Browser and the Server use to send data between them. In this case the protocol is exactly the same as HTTP except for the fact that the data is encrypted during transmission, and this is taken care of by the browser and server themselves and makes absolutly no difference to the HTML in your INET_ programs…HTML is HTML is HTML etc … Using HTTPS should be transparent to your OICGI app. If you receive a request that has been transmitted over SSL you may notice one or two differences in the header fields of the HTTPRequest variable that is passed to your INET_ procedure - these will allow you to detect if the request was made via SSL and therefore if any data you return will be encrypted: 1) The SERVER_PORT$ field should read 443 instead of 80 - this is the most reliable method. 2) The HTTPS$ field might contain a flag (but this is dependant on the individual web-server.) So, using this you can detect in your INET_ procedure if the request was made securely and if so only return the requested data then. As Don mentioned, the only other impact HTTPS should make on your system is the generation of HTML links - if you want your links to reference a page securely (be it static or dynamic) then use 'https:\\' instead of 'http:\\' and the browser will know to use SSL. The Sprezzatura Group World leaders in all things RevSoft www.sprezzatura.com_zz.jpg </QUOTE> —- === At 15 NOV 2002 08:44PM Dave Harmacek wrote: === <QUOTE>Thanks All. Cool, it is indeed. I've instructed my customer to purchase a server certificate. Dave </QUOTE> View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/bf9459890ebb4a5a85256c6c001152fe.txt
  • Last modified: 2023/12/30 11:57
  • by 127.0.0.1