Opening a document non encrpted with a password - aspose

I tried to open a PDF file not secured with a password with a password.
I was surprised that it was open without throwing an exception.
So my question is if there's any risk side effect with writing such code, I mean opening a non encrpted PDF with any password?
Thank you

#Khalil,
There is not any problem with opening such a file with password because the constructor internally uses the password only when encryption of file is certain. So you may keep the code as it is or better update it as under, for more clarity:
PdfFileInfo info = new PdfFileInfo(dataDir + "Aspose.pdf");
if (info.IsEncrypted)
{
//Source document is password protected
//TODO Code Here
}
else
{
//Source document is not password protected
//TODO Code Here
}
PS: I work with Aspose as Developer Evangelist.

Related

Activating Proxy service consumer from ABAP

I've just created a service consumer and generated its code from ABAP in order to send to the target WSDL system XML file which is created successfully.
The code should fill in the XML_FILE_INFO fields but have no idea if I did it OK:
The code to activate it:
" Call method, and receive a response
try.
lo_proxy->SET_MESSAGE(
exporting
INPUT = gs_input
importing
OUTPUT = ls_output
).
catch CX_AI_SYSTEM_FAULT INTO lo_AI_SYSTEM_FAULT. "lo_ai_system_fault_info.
catch CX_AI_APPLICATION_FAULT INTO LO_AI_APPLICATION_FAULT.
ENDTRY.
How should I fill the XML file's content in the GS_INPUT structure? IS putting the file's path in the FILE_NAME field enough?
If someone had already done something like the mentioned requirement I'd appreciate any help.
Thanks in advance.

Sitecore file download works only for admin user

I have a Sitecore 6.4 setup where an editor can click a button to generate a Word doc. I was adding the file to the media library and that was working fine. The editor would click the button in the content editor, the file was generated, media item was generated, then the content editor would show the new item in the media library and the editor could click the "download" button on the ribbon or the item to download it. However, my media library was getting unnecessarily filled up so I am trying to bypass the media library.
Instead of making the file in an arbitrary location as before, I am putting it in the temp directory like this:
wordOutputPath = Sitecore.IO.FileUtil.GetWorkFilename(Sitecore.Configuration.Settings.TempFolderPath, printItem.Name, ".docx");
File.Copy(wordTemplatePath, wordOutputPath);
WordprocessingDocument doc = WordprocessingDocument.Open(wordOutputPath, true);
After I "fill in" the file with content, I do this:
Sitecore.Context.ClientPage.ClientResponse.Download(wordFilePath);
Now if I am logged in as a Sitecore admin I get the browser's download dialog and can download the file. However, if I am logged in as a non-admin user, I get a little clicking and whirring, so to speak, and the file is generated, but the save file dialog never comes up in the browser. I can go in through the file system and see & open the Word doc, and it looks fine.
I found something in the Sitecore release notes for 6.6:
Released Sitecore CMS and DMS 6.6.0 rev. 130111 (6.6.0 Update-3)
[...]
Miscellaneous
Only Administrators were allowed to download files. (316774, 348557)
This was a problem in several areas of the system, for example the Package Generator and the Export Language Wizard in the CMS. It also affected the Export Users Wizard in the ECM module.
So I tried using SecurityDisabler (no longer have the code handy) and UserSwitcher like this:
using (new Sitecore.Security.Accounts.UserSwitcher(Sitecore.Security.Accounts.User.FromName("sitecore\admin", false)))
{
Sitecore.Context.ClientPage.ClientResponse.Download(wordFilePath);
}
The IUSR and IIS_IUSRS accounts both have read, list & read/execute permissions on the temp folder and the individual files show read & read/execute permissions for those two accounts as well.
What can I do to allow non-admin users to download these files? Does the bug that was fixed in 6.6 have anything to do with it?
Thank you.
Calling Sitecore.Context.ClientPage.ClientResponse.Download() method will result in a Download command sent back to the Sitecore Client in the Web browser, which in turn will make a call back to the server to execute it. This will be why using a security switcher (or a security disabler for that matter) before calling the Sitecore.Context.ClientPage.ClientResponse.Download() method has no effect, as the admin only restriction is being applied to the download else where.
If you search through sitecore\shell directory in your webroot, you will find that there is a file called download.aspx. This should be the actual page the download request is sent to. This web form page inherits the Sitecore.Shell.DownloadPage class, so if you take a look at that class's implementation, you will find that the OnLoad method is implemented as such:
protected override void OnLoad(EventArgs e)
{
Assert.ArgumentNotNull(e, "e");
base.OnLoad(e);
string fileHandle = StringUtil.GetString(new string[] { base.Request.QueryString["file"] });
bool flag = false;
string filename = FileHandle.GetFilename(fileHandle);
if (!string.IsNullOrEmpty(filename))
{
fileHandle = filename;
flag = true;
}
if (!string.IsNullOrEmpty(fileHandle))
{
if (MediaManager.IsMediaUrl(fileHandle))
{
this.DownloadMediaFile(fileHandle);
}
else if (fileHandle.IndexOf("id=", StringComparison.OrdinalIgnoreCase) >= 0)
{
this.DownloadMediaById(fileHandle);
}
else if (flag || Context.IsAdministrator)
{
this.DownloadFile(fileHandle);
}
}
}
As you can see, the last if block has an IsAdministrator check which would be where your non-admin users are getting blocked.
Although I haven't 100% verified that this is where the problem lies, the download restriction issue can be resolved, by creating a new class that inherits Sitecore.Shell.DownloadPage and overrides the OnLoad implementation with some extra security checks as required. I recommend that you don't remove the IsAdministrator check altogether as it is there for a good reason. Update the Inherits attribute in the download.aspx to make it use it instead.

How to make the login part in QuickFIX

How can I make the login part in QuickFIX in c++?
I found tons of tutorials and articles on how to do this on c# or java, but nothing on c++.
I have a server (acceptor), and a client (initiator). The username and password of the client are stored in the settings file, and are hardcoded in the server program.
From what I've read in the client I set the username and password in fromAdmin() and read and check the in the server in the toAdmin(), but how do I do that?
Here's what I've tried so far:
cast the message to a FIX44::Logon& object using:
FIX44::Logon& logon_message = dynamic_cast<FIX44::Logon&>(message);
Set the Username and password to the logon object like this:
if(session_settings.has("Username"))
{
FIX::Username username = session_settings.getString("Username");
logon_message.set(username);
}
And send the message like this:
FIX::Message messageToSend = logon_message;
FIX::Session::sendToTarget(messageToSend);
But I get this error on the cast:
cannot dynamic_cast 'message' (of type 'class FIX::Message') to type 'struct FIX44::Logon&' (target is not pointer or reference to complete type)
What I've tried I got inspired from http://niki.code-karma.com/2011/01/quickfix-logon-support-for-username-password/comment-page-1/.
I'm still not clear on how to make the client and the server.
Can anyone help me?
Possible mistakes:
I think you have fromAdmin()/toAdmin() backward. toAdmin() is called on outgoing admin messages, fromAdmin() is called on incoming. For the Initiator, you must set the fields within the toAdmin() callback. Your Acceptor will check the user/pass in fromAdmin().
Are you trying to dynamic_cast without first checking to see if it was a Logon message? The toAdmin() callback handles all admin messages; the message could be a Heartbeat, Logon, Logout, etc. That might explain your cast error.
As to what the code should look like, my C++ is rusty, but the basic pattern is this:
void YourMessageCracker::toAdmin( FIX::Message& message, const FIX::SessionID& sessionID)
{
if (FIX::MsgType_Logon == message.getHeader().getField(FIX::FIELD::MsgType))
{
FIX44::Logon& logon_message = dynamic_cast<FIX44::Logon&>(message);
logon_message.setField(FIX::Username("my_username"));
logon_message.setField(FIX::Password("my_password"));
}
}
From there, I think you can see how you'd write a similar fromAdmin() where you'd get the fields instead of setting them.
The above uses hard-coded user/pass, but you probably want to pull it from the config file. I think your calls to session_settings.getString(str) are correct for that.
(Please forgive any coding errors. I'm much more fluent in the Java/C# versions of the QF engine, though the basic principles are the same.)
I see that your first web reference uses the FIELD_GET_REF macro. It may be better than message.getHeader().getField(), but I'm not familiar with it.

Which winapi function will allow me to change logged in user's password?

I'm looking for a winapi function that will allow me to change current logged in user's password. In my case, I know current password of logged in user. I use Windows 7 Ultimate.
Thanks.
Background
The background will look weird, but I'm going to describe it for clarification. My personal home PC is used by several users (dad, sister, cousins etc.). I'm the only administrator of the PC. All others are standard user. All user accounts are password protected.
I don't like that other people use my account as they mess with anything. I always install all softwares from my account and also troubleshoot PC. When I'm away from my PC for several weeks, may be some other user need to install a software, or do something that require administrative right. For this reason they may need to use my account. There may be emergency cases, and I must allow the user to log into my account by giving account password.
I recently faced such a situation. Before leaving my PC for long time, I changed my regular password to something else. I'll change that again when I reach my PC.
So I'm thinking to write a tiny program that will run each time someone logs into my account. The program will only change current password to something else that I only know. In this case, if anyone logs into my account, installs something, logs out, and cannot logged back in as the password changes.
Suppose I set my account's password as abcd. When someone logs in, the program will change it to abcde. Next time may be abc123 and so on.
You're looking for NetUserChangePassword(). Check this MSDN link for sample code:
http://support.microsoft.com/kb/151546
You could use ADSI to connect to the local machine, get the user object and call the change password action.
MSDN doc on IADsUser::ChangePassword has the following example.
The following "C++" code example shows how to change a user password.
HRESULT ChangePassword(
IADsUser *pUser,
LPWSTR oldPasswd,
LPWSTR newPasswd)
{
HRESULT hr=S_OK;
if(!pUser) { return E_FAIL;}
hr = pUser->ChangePassword(oldPasswd, newPasswd);
printf("User password has been changed");
return hr;
}
The following VB code example shows how to get the user and change a user password.
Dim usr As IADsUser
Dim szOldPass As String
Dim szNewPass As String
On Error GoTo Cleanup
' Fabrikam is the MSDN fictional domain - us '.' for localhost
Set usr = GetObject("WinNT://Fabrikam/JeffSmith,user")
' Add code to securely retrieve the old and new password.
usr.ChangePassword szOldPass, szNewPass
Cleanup:
If (Err.Number<>0) Then
MsgBox("An error has occurred. " & Err.Number)
End If
Set usr = Nothing

Upload file to SharePoint WSS 3.0 with WebRequest PUT

Hey, I've got this nice little piece of code, much like all the other versions of this method of upload using WSS WebServices. I've got one major problem though - once I have uploaded a file into my doc list, and updated the list item to write a comment/description, the file is stuck there. What I mean is that this method will not overwrite the file once I've uploaded it. Nobody else out there seems to have posted this issue yet, so .. anyone?
I have another version of the method which uses a byte[] instead of a Stream .. same issue though.
Note: I have switched off the 'require documents to be checked out before they can be edited' option for the library. No luck tho .. The doc library does have versioning turned on though, with a major version being created for each update.
private void UploadStream(string fullPath, Stream uploadStream)
{
WebRequest request = WebRequest.Create(fullPath);
request.Credentials = CredentialCache.DefaultCredentials; // User must have 'Contributor' access to the document library
request.Method = "PUT";
request.Headers.Add("Overwrite", "t");
byte[] buffer = new byte[4096];
using (Stream stream = request.GetRequestStream())
{
for (int i = uploadStream.Read(buffer, 0, buffer.Length); i > 0; i = uploadStream.Read(buffer, 0, buffer.Length))
{
stream.Write(buffer, 0, i);
}
}
WebResponse response = request.GetResponse(); // Upload the file
response.Close();
}
Original credits to: http://geek.hubkey.com/2007/10/upload-file-to-sharepoint-document.html
EDIT -- major finding .. when I call it from my nUnit test project it works fine. It seems it only fails when I call it from my WCF application (nUnit running under logged on user account, WCF app has app pool running under that same user -- my account, which also has valid permissions in SharePoint).
Nuts. "Now where to start?!", I muses to myself.
SOLVED -- I found a little bug - the file was being created in the right place, but the update path was wrong.. I ended up finding a folder full of files with many, many new versions.. doh!
Why not use the out-of-the-box SharePoint webservice, Lists.asmx? You'll find it in
http://SITEURL/___vti_bin/Lists.asmx
Edit, I checked out the link and it seems you are calling the out of the box web service. This has got be versioning related then. Can you check out the different versions that exist in the doc lib of the specific file? see if it perhaps gets added as a minor version through the service?
Have you tried using a capital T? SharePoint's webdav header processing is not very likely to be case-sensitive, but the protocol does specify a capital T. Oh, and what is the response? A 412 error code or something altogether different?