I have asked this question of Embacadero Tech Support, raised a case there, but wondered also if anyone here knew an answer to this.
I work for a retail company and have written their Mail Order program in Delphi.
One thing the programme relies heavily on is processing credit card data. Since day one, this has never been much of an issue. Our gateway provider is Verifone in the UK and up until now I have used a SOAP requester to talk to the Verifone processing servers. I didn't have too many issues getting this working and it it has worked ever since. I don't profess to being an expert in SOAP calls etc though. This software, for component legacy reasons, resides still in D2007 and it is fine that way. I can still develop it as needed.
Until now......
Yesterday I received an e-mail from Verifone stating the following:
"On Tuesday 4th October 2016, Verifone will be making the following changes:
1. Upgrade security certificates from SHA-1 to the more secure, SHA-256 algorithm.
2. Retire support for SSL v3 and TLS v1.0."
They provided a link to this page:
http://www.verifone.co.uk/support/ssl
To begin with, I wasn't overly concerned, we have had some similar changes in the past (although mainly certificate changes) and this hasn't effected us. But the more I read it, the more I became a little concerned.
So I decided I had better run some tests. On that page on the second tab, there are some test URLs. I swapped our existing test URL (the test one we use for training on the system) with the new test one and...... it failed. I get the error:
"A connection with the server could not be established - URL:http://xml-cst.cxmlpg.com/gateway/gateway.asmx - SOAPAction:https://www.commidea.webservices.com/GetServerStatus"
Or similar to this screenshot which is an actual test credit card check rather than a server status check:
This was just doing a simple 'GetServerStatus' call which requires no account or credentials. I know the server is working using this URL in Chrome:
https://xml-cst.cxmlpg.com/gateway/gateway.asmx?op=GetServerStatus
I began to wonder if this was an issue in the components for the SOAP call in D2007.
So last evening I tried it at home in Seatlle. My thinking was that if I could at least getting it going there then I could write a little utility in Seattle that just sat alongside the D2007 Mail Order suite just to process the credit cards. I imported the WSDL from:
https://xml-cst.cxmlpg.com/gateway/gateway.asmx?wsdl
using the WSDL importer and added a button to a form to call the GetServerStatus function (in the same way that I got the original working in D2007):
procedure TForm1.Button1Click(Sender: TObject);
var
gs : GatewaySoap;
begin
gs := (HTTPRIO1 as GatewaySoap);
gs.GetServerStatus
end;
I kept my fingers crossed and clicked the button.
Alas, I got the same error message as above. So now I assume it is nothing to do with the Delphi version at all.
This is a very scary issue as basically it totally stops the automated functionality of the mail order software of which this is part. If I can't get the simple GetServerfStatus to work, then I am at a total loss.
Has anyone any ideas what is happening here? Is it that I can't do non-SSL/TLS1.0 via the SOAP requester? It looks like it has to be TLS1.1/1.2. How can i resolve this issue? I am guessing now that if it can resolved for Seattle then the same solution might apply to the existing Mail Order code in D2007.
Really hoping someone can help me out on this one! I was up verfy late last night trying different things, but can't get to grips with it. It could literally be somethhing I have just overlooked, something simple - which is my hope. Then again, I suspect it may be something a lot more technical.
Trevor
It seems the SOAP server is returning http URLs for its services in the published WSDL (whereas they should be https).
If you control the SOAP server you should fix the WSDL generator. (If it's written in Delphi it's quite probably just missing poPublishLocationAsSecure option in their TWSDLHTMLPublish.PublishOptions property.
A possible workaround on the client might be to use a (https) URL directly and not rely on the published WSDL.
Related
When I use MS Edge, Firefox or Opera to access Cloudfare-protected webpages, it shows the page correctly. However, using TWebBrowser it always shows the Cloudfare captcha page first.
How do I configure Delphi TWebBrowser to act like a "real" web browser which does not invite the Cloudfare page?
Note that this is occasional access to the page, and yet it triggered the cloudfare when the other browsers do not trigger at that same point in time.
Not an real answer but some things i encountered with TWebBrowser on the "real" Internet.
The Sites i encountered needed different things.
Some needed a Header Information with specific Browsers.
Executing java script to read your system envronment for language (geoblocking)
Some need cookies obtained through cross site Scripting (Fraud protection)
and many other Things for various reasons.
So, for your Target Website you can sniff where your call beginns to differ from a working Browser. And then trying to reproduce the functionality for Your Application.
What you encounter is not a TWebBrowser Problem in itself. It is Browser Funtionality used to have Features like Geoblocking, Addblock detection or whatever. So you need to implement the missing Parts: Cookie Storage and/or Java Script.
The downside is: you only find one missing Part after the other. So when you start you dont know if you will hit a dead end. Doing "real Internet Sites" with TWebBrowser (based on IE 5.5) was not easy and that was around 2005 ... in the early easy days...
Optional: If you have an Invitation from the Site owner through an Api Key (or something similar for Authentification) it should work with the TWebBrowser. If all the "Protection" is not needed it worked on almost everyting.
I never found a solid working Solution, but changing the Header to be IE5.5, enabling the newer Mode(non legacy?) and Cookies + Script helped.
If possible try it with the new Edge Component or an embedded Chrome / Firefox / Opera.
In the End we used a microsoft IE COM Component and not the Delphi Component. But even then, not everything was working.
I'm running an IIS web site (built using ASP.NET/MVC) that among other things collects files from multiple agents that anonymously upload the files via BITS.
I need to make sure that only files uploaded from known sources as well as matching certain predefined file name pattern will be accepted by IIS. All other BITS upload attempts must be cancelled.
As I understand, BITS uses an ad hoc protocol over HTTP 1.1 using "BITS_POST" verb. So, ideally, I'd like to hook into IIS, analyze a BITS_POST request info and if it does not satisfy my pre-conditions, drop the request.
I've tried to create and register a filter implementing IActionFilter.OnActionExecuting, but it seems that my filter does not receive BITS_POST requests.
I'd be glad to hear if somebody have implemented similar BITS related solutions and how this was done. Anyway, other ideas are welcome too.
Regards,
Natan
I have never worked with BITS, frankly i dont know what is it.
What i usually do is such situations is implement an HTTP module. On its begin request event, you can iterate through incoming HTTP request data and decide to stop processing the request if data is not complying with requirements. You have full access to HttpContext.Current.Request object from HTTP module code.
With HTTP modules, you can execute .NET code even before entering the ASP.NET pipeline.
While I was following the guide http://msdn.microsoft.com/en-us/library/vstudio/jj920163.aspx to add Bugs to the task board I ran into an unexpected issue.
Adding the fields to the WIT was successful but when I started adding the form fields I received a very strange error:
Failed to save the 'Bug' Work Item Type to the server. Please contact
your administrator. There was an error contacting the server.
Technical information (for administrator): HTTP code 200: OK
Now I played around trying to find what field was causing the error... I tried every field seperatly and when added seperately they worked, then I tried adding them in pairs, this worked as well, then I tried adding all of them and even this worked!
BUT: When I try to add all of them in a clean group and column I get the error!
This leads me to believe there is some sort of maximum amount of elements in the layout form of a WIT? For now we have left all the fields added to another category but I wanted to ask if someone else had run into this issue and if there is a solution for this?
Since these are all stored as columns in a SQL Server table, the maximum you can add is 1024 (less the TFS standard, which might be around 33 columns?)
If you think this is the problem, check the Tfs_Warehouse..DimWorkItem table and see if you exceed the maximum.
Any chance you can get more information from the event viewer log on the app server, or provide more information about your bug? That message isn't very useful.
For reference -
http://blogs.msdn.com/b/eugenez/archive/2009/05/07/work-item-customization-tidbits-limits-of-complexity-part-13-of-x.aspx
Today we figured out what was going on by using fiddler and more closely monitoring the exchange between Visual Studio and our TFS server. Apparently the request was hitting the Application Firewall that was installed on the TFS server. This is the reason why you receive the vague error HTTP code 200: OK. The Application Firewall replies with a plain HTML page containing a blocked request ID (so you can pass it to your system admin). Once we passed this ID on to our networking team and they adapted the rules there was no longer an issue.
I hope this helps anyone who unexpectedly runs into an Application Firewall on your TFS server like I did.
I have a SOAP server/client application written in Delphi XE working fine for some time until a user who runs it on Windows 7 x64 behind a corporate proxy/firewall. The application sends and receives TSOAPAttachment object in the request.
The Problem:
Once the first request from this user is received and processed, the server could not process any request (from any user) successfully coming after this.
The server still response to the request, but the SOAPAttachment of the request
seems corrupted after the first one from this user, that's why it couldn't process the request successfully.
After putting may debug logs to the server, I noticed the TSOAPAttachment.SourceStream in the request's parameter become inaccessible (or empty), and TSOAPAttachment.CacheFile also empty. Therefore whenever trying to use the SourceStream, it will return Access Violation error.
Further investigation found that the BorlandSoapAttachment(n) file generated in the temp folder by the first request still exist and locked (which should be deleted when a request is completed normally), and BorlandSoapAttachment(n+1) files of the following request are piling up.
The SOAP server will work again after restarting IIS or recycle the application pool.
It is quite certain that it is caused by the proxy or the user’s networks because when the same machine runs outside this networks, it will work fine.
To add more mystery to the problem, running the application on WinXP behind the same proxy have no problem AT ALL!
Any help or recommendation is very appreciated as we have stuck in this situation for some time.
Big thanks in advance.
If you are really sure that you debugged all your server logic that handles the attachments to attempt do discover any piece of code that could failed specifically on Windows 7, I would suggest:
1) Use some network sniffer Wireshark is good for this task, make two subsequent requests with the same data/parameters values, and compare the HTTP contents. This analyze should be done both in the client (to see if the data is always leaving the client machine with the same content) and also in the server, to analyze the incoming data;
2) I faced a similar situation in the past, and my attempts to really understand the problem was not well succeed. I did workaround the problem sending files as Base64 encoded strings parameters, and not using the SOAP attachments. The side affect of using Base64 its an increase of ~30% in the data size to be sent, and this could be significant if you are transferring large files.
Remember that SOAP attachments create temp files in the server, and Windows 7 has different file access rules than Windows XP. I don't know if this could explain the first call being processed ant the others not, but maybe there are something related with file access.
Maybe it is UAC (User Access Control) problem under Win 7. Try running the client in win 7 "As Administrator" and see if it is working properly.
I'm working on a Firefox add-on. At one point in the add-on, it needs to contact my server, give it a URL, then the server will process the URL (it's not a quick or easy process) and send back a link to the resulting file (on Amazon S3). However, since Firefox add-ons are mostly open-source by nature, how can I protect that one call to the server from being discovered by malicious people and then abused? (I only want users of my add-on to be able to make that call to the server...)
I was thinking about using some sort of key or something, but since Firefox add-ons are all open-source that wouldn't really work. I also thought about writing a binary component, but I have almost no experience in C++ (but maybe for something simple like this I could learn) - but then how could I protect calls to the binary component? Also, how could I protect from network sniffers and such? Would it be possible to somehow include encryption of some sort in that binary component so network sniffers cannot detect what is being sent to the server? (I found this question: Client-Server security and authentication but it was a bit over my head.)
When you distribute an extension you are basically giving people the car keys, so it's hard to stop them from taking the car for a joyride. The most secure solution is the one you suggested: use a binary component and authenticate the connection with username/password or PKI certificates. If you use HTTPS then the connection will be encrypted. This isn't totally secure (the binary component could be reverse-engineered by a determined hacker) but it will certain deter casual attacks. Note, however, that implementing, building and maintaining a binary component is significantly harder than the JavaScript equivalent.
An alternative would be to put the user through a one-time registration process when they install the extension. This could even happen in the background, and the user would get some credentials (e.g. a PKI key pair) at the end that they would use for subsequent communication with the server. If you're worried about people overusing the server, then presumably doing so via the extension wouldn't be great either. This way you can track the usage of each user (via the extension or not) and limit it as necessary.
In the end I don't think that there is much you can do. You could have a binary library in your add-on and call it via js-ctypes (it is easier to implement and maintain than a binary XPCOM component). But nothing will stop people from taking your extension and changing its JavaScript logic in any way that they like. You can make it harder by using some logic like this:
Client to server: "Extension version 1.2.3 wants to make a request."
Server to client: "Take your chrome://... file, bytes M to N, what SHA1 checksum do you get for them?"
Client to server: "SHA1 checksum is ..., please process URL ... now."
But this is also everything but fail-proof, it merely makes abusing your service somewhat harder. Same goes for automatic registration - if your extension can register then an attacker can create an account as well.