I am using chilkat active x to access a webservice secured with x509.
SetSslClientCertPfx("pfxfilewithpath","password")
It works fine with the pfx file in the location I used it first.
If I copy it to another path it does not work anymore (error 109) , even after pc reboot or renaming.
Any chance to get this to work ?
Thanks in advance
tom
Using locert.LoadByCommonName("certname") and SetSslClientCert(locert) works but I would prefer to use SetSslClientCertPfx()
Examine the contents of the httpObject.LastErrorText property after calling httpObject.SetSslClientCertPfx (assuming this is for HTTP).
Related
We have a server on windows, but it has a network drive which is actually on a linux server. The Program has to delete a file at the same location with the same name (signals), it works ok when those files are on local drive, but when running on the network drive, it will sometime not delete the file, and even worse, the functions will return that everything went ok(meaning the file is deleted). I tried with remove, _unlink, DeleteFileA , the problem still persists,sometime completely at random it won't be deleted and it will stay like this.
The code is really simple:
bool File::Delete()
{
if(isFile() && exist())
{
return DeleteFileA(filename.c_str()) != 0 ? true : false;
}
else
return false;
}
This will always return true even if the file is not removed, if for example it would not have permission it should fail(and fail each time, not at random), could someone give me an idea ? I ran out of options :(
Edit:
Thanks to #ExcessPhase, it seems like moveFile actually detects an error, so renaming before deleting can detect a problem "ERROR_FILE_NOT_FOUND".
Other things : This random problem can only happen when the files are created from linux server. If I create them from windows, they will always be deleted. Even more: If I have a file that the program cannot delete, and I create another file next to it from Windows, the program will detect and delete the one it could not delete before.
Edit2: Closer to answer: filename test and TEST in linux is different, while in Windows it's the same. The problem seems to appear at random when the case don't match. But I'm not sure since it's so random.
I believe the problem is with Samba service on Linux, which implements the SMB protocol for Windows. DeleteFile function just requests the SMB server (Server service on Windows) to delete a file. The success is returned by Samba.
Maybe you should try something more higher level like boost file system, or std::experimental::filesystem::remove
I wrote a bit of code that reads/writes stuff...
I would like to add an option to read/write to UNC paths.
A bit of code:
if (boost::filesystem::exists (file_name))
{
std::ifstream in_file(file_name.c_str(), std::ios::in|std::ios::binary|std::ios::ate);
if(in_file.is_open())
{
in_file.read(...);
in_file.close();
}
}
If the network share I am trying to use has been used before, this works.
But if I try with a share from a computer that I have not seen before, I get error:
boost::filesystem::status: Logon failure: unknown user name or bad password: "\\xx\test.txt"
I'd like to avoid the exception, check the boost::filesystem::status for... what ? Looking in documentation, it seems that it can tell me if I have a regular file, or a directory... but how can I check if I have the correct permissions ?
Is there a way to actually send in the user name and password ?
Edit: found that I could call
Net Use \\yourUNC\path /user:uname password
also:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa375187(v=vs.85).aspx
I think either of these would make the code platform dependent ?
Also, if I do log in every time - in a sequence of 10000 calls, this would result in serious slowing down ?
Is there any way to check if the user is logged in ?
Note: I am using boost 1.47 - mostly windows but I'd like to be platform independent.
Thank you.
The only way I found that I can check rights was to try... catch surrounding a check for file exist call.
If the try fails, it means I don't have rights and can call system("Net Use...")
This way, I only have to log in once even if I read/write 10,000 files...
I don't like the fact that I have to use try... catch, if there is a better way, and I'll find it, I'll update - if anyone knows of a better way, please let me know.
I am using MAPISendMail() in an MFC application, and am having a problem that webmail clients sometimes receive a winmail.dat attachment, instead of the "real" attachments.
I have researched a lot, and have found that others are experiencing this problem too, but have not found a solution.
I believe that the problem may be in my MapiFileDesc structure, in which I leave the lpFileType member pointing to NULL, in order to have the mail program (In my case Outlook 2010) determine the file type automatically.
lpFiletype is a MapiFileTagExt structure, and the documentation says this:
A value of NULL indicates an unknown file type or a file type determined by the operating system.
So I believe this should work for common types, such as JPEG or GIF and such.
I read that the winmail.dat is caused by Outlook sending the mail encoded with the ms-tnef encoding, which is proprietary to Microsoft. However, when sending the email, Outlook shows "HTML" as highlighted, not RTF.
Has anyone encountered this problem and properly solved it?
Sending via SMTP and such is not an option, because the user should have a copy of the message in their Sent Items folder.
Using the Outlook object model is not an option, because that would require the user has Outlook installed, and not any MAPI compatible client.
I was having similar issue.
I found a KB article that has interesting information in "One-Off Addressing" section, saying that when address is provided in the format [SMTP:SMTP Address] - then e-mail is always sent in rich text format.
For me the fix was not to set "Address" property of MapiRecipDesc object at all. Instead I put the address in Name property. The opening dialog then does not resolve the address at first, but it resolves it right before sending and then it is not sent in RTF!
I even got it working with recipient's name together with address:
MapiRecipDesc.Name = "Firstname Lastname <mail#address.com>";
I, too, was getting all attachments as WinMail.Dat files for the jclMapi.JclEmail, InternalSendOrSave routine, which is called by jclEmail.Send.
What I did was essentially follow jtmnt's answer and changed:
RealAddresses[I] := FAddress; //do not add the Recipients.AddressesType + AddressTypeDelimiter
and I changed:
lpszName := PAnsiChar('"' + AnsiString(RealNames[I])+'" <' +
AnsiString(RealAddresses[I]) + '>');
lpszAddress := '';
This worked so that I no longer was sending WinMail.dat files as attachments, instead the intended PDFs and MP3s were being sent.
What I really want to report is that I was using an OLE routine that was working fine in Windows 7 and stopped working in Windows 8. Thus, I started looking at the MAPI solutions but found this problem with Winmail.dat files being attached. I could not find any mention of this issue with OLE (with Outlook) not working properly in Windows 8.
(Both:
OutlookApp := GetActiveOleObject('Outlook.Application') and
OutlookApp := CreateOleObject('Outlook.Application')
were no longer working in Windows 8, but continued to work fine in Windows 7.)
Thanks for the solution. Thought you might want to know how to apply it to the jclMapi code and this issue with OLE in Win8.
Curious in Outlooks behavior is it does matter what length the domain name of the recipient has! If the e-mail address domain is 12 characters or more (I don’t know what the limit exactly is), then we face the problematic TNEF coding.
So: a#hutsfluts.nl goes wrong. While abacadabraandmore#hf.nl will result in plain text encoding.
I guess this is not by design….
The solution mentioned above:
Put the recepient e-mail address in MapiRecipDesc’s lpszName and let the lpszAddress point to an empty string (NOT null!) solves the problem.
Don’t ask me why, for I have no clue why this would influence the encoding.
I've spent all night researching this without a solution.
I'm trying to verify the digital signature of a file in the drives folder (C:\Windows\System32\drivers*.sys) pick whatever one you want. I know that the code is correct because if you move the file from that folder to C:\ the test works.
WinVerifyTrust gives error 80092003
http://pastebin.com/nLR7rvZe
CryptQueryObject gives error 80092009
http://pastebin.com/45Ra6eL4
What's the deal?
0x80092003 = CRYPT_E_FILE_ERROR = An error occurred while reading or writing to the file.
0x80092009 = CRYPT_E_NO_MATCH = No match when trying to find the object.
I'm guessing you're running on a 64-bit machine and WOW64 file system redirection is redirecting you to syswow64\drivers, which is empty. You can disable redirection with Wow64DisableWow64FsRedirection().
if you right click and view properties of file can you see a digital signature? most likely your file is part of a catalogue and you need to use the catalogue API to extract the cert from cert DB and verify it.
I am fetching the call-logs, appending them on information note using:
CAknInformationNote* note = new (ELeave) CAknInformationNote;
note->ExecuteLD(callLogs);
I perfectly run on emulator (show all call-logs on note) but nothing shows up when run on the actual device (a Nokia N73). Any ideas?
i think you should use some kind of file logging(you can even use RFile) and see till what point your application executing.i am assuming you dont see a crash/panic on hardware.i doubt if you are able to get the call logs properly first on device.