Delphi & SmartCards - delphi

Does anyone have experience integrating SmartCard authentication in their Win32 apps? If so, are there any preferred libraries?

Try SecureBlackbox, A component that works fine for me, a second choice can be
Delphi PC/SC SmartCard Component 0.91.
try

Well I guess that you have an SmartCard reader ... if so (and if you don't have one I don't know how you are going to manage this) then it must have some interface, RS232, USB, TCP/IP ... any one will do.
Communication protocol usually is available at SmartCard reader manufacturer. Few lines, and you will have it working in Delphi.

You need to read the developer manual that comes with reader you're going to use. It might only use PC-SC (by MS) to communicate, if so you can use the component specified by RRUZ, however it doesn't work with D2009. Otherwise you'll need to use API provided by SDK.

Related

Possible to create a zeroconf service with Delphi XE5?

Working on an appliance and would like to support zero configuration feature. That way users can look for the device on the network and simply double click an icon to access the web interface without having to configure it or know its ip address.
Tried to use UPNPLib_TLB but functions seem to be read-only; am I right? I can create a device using CoUPnPDevice.Create but can't set a FriendlyName or a URL.
Tried to use Deltics Bonjour service but it crashes on create (ACCESS_VIOLATION). The demo code uses a custom test unit which complicates experimentation.
After much research it does not look like there is a component available for this and would appreciate some pointers. Has anyone successfully created a zeroconf broadcast either via UPnP or Bonjour with Delphi XE2/5.. I can go back to Delphi 7 if required. Target = Windows 7.
NOTE: To be clear, I can find existing devices on the network and don't want to enumerate existing devices but what I want is to broadcast my service so that my box behaves like a network printer for example. The only service I need to expose is the URL so that users can access an embedded web server.
Appreciate the help!
EDIT
With the tips provided I did some research and getting this done the RAD way is not possible.
Using MS APIs directly is time consuming and requires a level of understanding of C that I don't have. Porting the Delphi 5/Indy 7 component to XE2/5 will require a good amount of work and debugging.
I discovered UPnP developer tools from Intel now open source here: Developer Tools for UPnP. This tools makes it really simply to create a server in 10-15 lines of code. Intel provides a DLL that I can call from VS Express as follows and it works great:
device = UPnPDevice.CreateRootDevice();
device.FriendlyName = 'My name';
device.PresentationURL = 'URLToEmbeddedServer";
..
I tried to use headconv7 tool to convert the .h file Intel's UPNP.DLL to a pascal file and call the external functions within the DLL directly from Delphi but there were too many problems with the conversion.
It's too bad because the Intel library makes it really simple to create UPnP stacks and the approach would apply itself very well to a component but for now its quicker to use .NET and VS Express to get the job done.
When using UPNPLib_TLB, you are not supposed to create a UPnPDevice object directly. UPnpDevice describes a known device on the network, which is why its properties are read-only.
Read the documentation:
Control Point API
Finding Devices
You are supposed to create an instance of the UPnPDeviceFinder class instead. Its search methods will give you a UPnDevice object for each device that is found.

Does the Firefox add-on sdk allow direct modification of the http response byte stream?

I am working on a project I intended as an academic exercise for myself. What I am basically doing is trying to add a custom compression type between an IIS server and a web browser, but getting mired in the browser aspects of it. What is basically needed is to be able to alter the byte stream on the server before it is sent to the client, and on the client browser side, be able to alter received response byte stream before other normal DOM parsing and such take place. On the server side this turned out to be pretty trivial, but I am at a loss in how to do this in chrome or firefox. If anyone has insight for chrome, please share, but I'll focus on Firefox for now. My understanding is that previously Firefox had rather low level access available to extensions but that they are tightening the restrictions a bit going forward with their Firefox add-on sdk. I don't want to bother learning the old methods if they are slated to be removed so does anyone definitively know if the add-on sdk allows you to alter the byte stream directly in this manner? If so, do you have an example of such usage?
(I am aware that I need to have the compression negotiated with the Accept-Encoding header)
I don't want to bother learning the old methods if they are slated to be removed
There are no plans now, or in the future, to remove legacy add-on support. At least that's what add-on SDK folks and extension manager folks told me repeatedly.
Back to your question: The add-on sdk does not provide an explicit API for stuff like this, but you can always go even more low-level, even in the SDK (via the chrome module and/or window/utils).
To implement additional compression methods, you'd need to implement the nsIStreamConverter interface and properly register your component under the #mozilla.org/streamconv;1#?from=<yourcompression>&to=uncompressed contract. Then Firefox should be able to decode yourcompression.
See https://developer.mozilla.org/ for more information on how to implement and register XPCOM components in either javascript or C++.
Using the SDK or implementing your add-on restartless will require you register the component yourself instead of relying on chrome.manifest. There are a couple of add-on doing so already, e.g. Adblock Plus.
Binary (C++) components should be avoided because you'll obviously need to compile your component for each supported platform and you'll need to re-compile it for each Gecko version. If you have to go binary, a javascript component stub + js-ctypes might be better.
See the mozilla source code on how to implement nsIStreamConverter in the first place.
You may also need to modify the network.http.accept-encoding preference so that the compression may be actually negotiated with the server.

Can i call a web service from FireMonkey for iOS?

I'm new to iOS, have been developing in Delphi for many years.
I don't know FPC well and i find it very hard to figure out which classes are available on iOS.
is there any FireMonkey classes for calling web services and parsing xml?
Yes you can call a webservice :)
No it is not simple :(
You need to access the iOS framework directly...
The following code fragments will help...
First a pascal example of how to send/receive data via TCP
https://forums.embarcadero.com/thread.jspa?messageID=397346
Secondly, you will need to wrap the call using the relevant headers. See...
http://books.google.com.au/books?id=0nTYIL3-0yoC&pg=PT518&lpg=PT518&dq=beginning+ipad+development+webservices&source=bl&ots=cYniLvL8z2&sig=Ci6HskHgMvUeIrjyUbDecd7fBCQ&hl=en&ei=0_KdTpzBB4nOrQfwzM29CQ&sa=X&oi=book_result&ct=result&resnum=6&ved=0CEAQ6AEwBQ#v=onepage&q&f=true
It is a fair bit of work, but it can be done. Good luck!
You can also try to use RealThinClient (RTC) SDK to allow your Delphi XE2 FireMonkey iOS client to connect to a RTC SDK server. Not SOAP, but I've managed to send data back and forth between the two layers (just in case you do not have to use SOAP, but are merely looking for some way to connect an iOS client to a server)...

Delphi - loging all HTTP request

I need loging all HTTP request (from any application).
I have Delphi 7.0.
Anybody know how do that?
I looked into whether the Indy components could do this but found an old newsgroup response from Remy Lebeau that said:
If...you want to look at the traffic
that other applications are
generating, then no, you cannot use
Indy for that. That is outside the
scope of what Indy is designed for.
You would have to write your own NDIS
driver for that kind of capturing. Or
use a third-party sniffer API, such as
WinPCap.
What about WireShark?
There is also a product called Fiddler. I have found this extremely useful to track down exactly what the Indy components are sending/receiving. The one drawback is you have to utilize a proxy. This isn't a problem with Indy components and browsers such as Firefox. But if you need to capture for all applications you would need to be able to set a proxy for those apps.
if you want to go deeper and want pure delphi thing, there is winsock logger program floating around, google might help you ( it hooks winsock apis though).
Do you have to write a Delphi app to do it? Could you use an application like ethereal?

Porting Windows demo apps to WinCE/XP Embedded

We have a range of PC demonstration programs for our microcontroller products. The programs typically connect to a USB HID chip on the microcontroller board. The USB chip acts as a communications bridge, allowing the programs to communicate with the micros over SPI/I2C/UART. The programs can configure the micros, and get back status information to display to the user.
We are now looking to build some standalone demonstrations using single board PCs. We would like to reuse as much as possible of our existing demo app source code. Ideally, we could just run them as-is.
Does anybody have any advice on the best way forward? The basic options seem to be WinCE or XP Embedded boards. WinCE boards seem to pull less power, which would be an advantage from a battery life point of view.
Our existing demos are built either in C++ under Borland Builder, or in Delphi.
Thanks in advance.
EDIT: see my answer below with info from a board vendor.
Free Pascal/Lazarus can compile some forms of Delphi apps to WiNCE/arm. Even visual ones.
There isn't a Delphi version for WinCE, so you would need to rewrite the applications. The same applies for the Borland Builder's control libraries. Only if you have used plain Win32 API, you would be able to port your application to WinCE easily. You may also encounter problems with the hardware access part. The Serial Port driver may not work as is. Also, you need to find a WinCE board that can act as USB host and provides HID drivers (this isn't very common).
In conclusion, I believe that you would be better of with Windows XP Embedded boards. These should run your applications as they are.
As an update, and for future reference, I thought I'd post the results of our discussions with a WinCE board vendor here. Caveat: I haven't actually tried any of this.
The bottom line is that there isn't a straightforward way to do what we were hoping for (i.e., re-compile our existing demo applications to run under WinCE). The reason is that the generic HID drivers and standard APIs that exist in desktop flavours of Windows just aren't there in WinCE.
To talk to HID devices in WinCE you need to implement a custom HID driver. This needs to support an interface allowing user mode applications to communicate with the driver, and to construct HID reports to be sent to the physical device. As this interface would itself be custom, application code needs to be updated accordingly.
WinCE application development is generally done using Visual Studio and the Microsoft compilers. The approach recommended to us was:
Create a custom HID class driver. This could be based on, for instance, the Microsoft keyboard HID driver.
Create an API for talking to the driver.
Use .net to create our GUI applications, and use PInvoke to actually talk to the API.
The end result of all this head-scratching is that to avoid the time and learning curve associated with this approach, we're going to go for a board running XP. We can then use our existing demo applications straight out of box. The trade-off is that we'll have to live with substantially reduced battery life.

Resources