incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fan Zheng <zheng.easy...@gmail.com>
Subject Re: Propose for 3.4.1: Can't remove password from file (119366)
Date Tue, 26 Jun 2012 10:24:47 GMT
Now the new patch was updated onto bugzilla, for you review.

2012/6/26 Fan Zheng <zheng.easyfan@gmail.com>

> Root cause:
>
> Seems the logic of "Save As" and "Save" inside Apache OpenOffice is pretty
> weird anyway.
> A, inside AOO, the method SfxBaseModel::StoreSelf is the entry for storing
> file into the original URL path if it has one. Which means, such method is
> responsible to:
>
> 1. Directly "Save" request, but exclude the very first time on "Save"
> without original URL path;
>
> 2. "SaveAs" request, with the same URL information as former;
>
>
> B, as such method is only focus on storing back into to original file, it
> is designed as an incremental saving pattern for certain efficient
> consideration. Which means,
> such function do not allow external saving parameters except the ones on
> changing "Version Comments", "Author", "Interaction Handler" and "status
> Indicator".
>
> C, "Saving with password" is a kind of external saving parameter. The
> saving parameters set will contain a password item inside, if users have
> enable the check box
> "Save with password" in "File Save As" dialog. Otherwise, saving
> parameters set wont contain password corresponding items.
>
> Combine the above 3 conditions, we can take a deeper inside look of
> following scenarios:
>
> 1. In the "Save" request, whatever the password originally enabled or not,
> as no further different setting applied, the storing process will directly
> apply the former saving parameters set, including the URL path and password
> setting stuff. Everything is OK.
>
> 2. And in the "SaveAs" request with password originally disabled:
> 2.1 If the user keep the "Save with password" disabled in "File Save As"
> dialog, as no further setting applied, the storing process will directly
> apply the former saving parameters set, still with password disabled. Keep
> the consistence between UI setting and exact result and high efficiency;
>  2.2 If the user change the "Save with password" from disable to enable
> in "File Save As" dialog, as external saving parameter was added into
> saving parameters set, which do not satisfy the verification of parameters,
> such "SaveAs" request will be returned from SfxBaseModel::StoreSelf, and
> actually finished inside the common "SaveAs" method with password enabled.
> Also keep the consistence between UI setting and exact result;
>  3. In the "SaveAs" request with password originally enabled:
> 3.1 If the user keep the "Save with password" enabled in "File Save As"
> dialog, as external saving parameter was added into saving parameters set,
> which do not satisfy the verification of parameters, such "SaveAs" request
> will be returned from SfxBaseModel::StoreSelf, and actually finished inside
> the common "SaveAs" method with password enabled. Keep the consistence
> between UI setting and exact result, but with lower efficiency;
>  3.2 If the user change the "Save with password" from enabled to disabled
> in "File Save As" dialog, as no further setting applied, the storing
> process will directly apply the former saving parameters set, still with
> password enabled, as oppose to the UI setting. The issue happens.
>
> So, a reasonable solution of this issue should be:
>
> 1. No process and saving parameter change on scenario 1 and 2;
> 2. In scenario 3.1, remove the external password parameter as the
> originally enabled, and makes it finished in StoreSelf for higher
> efficiency;
> 3. In scenario 3.2, do not trying to use StoreSelf anyway;
>
>
> For you reference.
>
> The code patch will be submitted for reviewing later.
>
>
> 2012/6/25 Oliver-Rainer Wittmann <orwittmann@googlemail.com>
>
>> Hi
>>
>> On 25.06.2012 13:32, Fan Zheng wrote:
>> > o, i miss the situation you mentioned. OK, i will keep on working with
>> this
>> > issue. thanks a lot!
>>
>> No problem.
>> I have assigned this issue to you.
>> I am looking forward to see your solution.
>>
>> Best regards, Oliver.
>>
>> > 在 2012-6-25 晚上7:11,"Oliver-Rainer Wittmann" <orwittmann@googlemail.com
>> >写道:
>> >
>> >> Hi,
>> >>
>> >> On 25.06.2012 10:20, Fan Zheng wrote:
>> >>
>> >>> Hi, All:
>> >>>
>> >>> This issue was solved, now call for the reviewers.
>> >>>
>> >>> In general, this is a setting confusion issue. In current saving
>> process,
>> >>> both SID_ENCRYPTIONDATA and SID_PASSWORD are working for setting
>> password
>> >>> on a document.
>> >>> Refer to the SfxObjectShell::ExecFile_Impl(**) in file
>> >>> SRC/sfx2/source/doc/objserv.**cxx:line 595-599 please.
>> >>> And, as what we imagine, after doing the file dialog executing with
>> >>> deselecting the check box of "Save with password", the result
>> parameter
>> >>> set, which is to customize saving process, wont record said 2 SID
>> inside
>> >>> anymore, for indicating that the following saving process will not
>> concern
>> >>> about the password stuff anymore.
>> >>> But when performing the exact preparation SaveAs process in
>> >>> SfxobjectShell::PreDoSaveAs_**impl(), only the the default
>> SID_PASSWORD
>> >>> was
>> >>> cleared, but  SID_ENCRYPTIONDATA  was not. The issue happens.
>> >>>
>> >>> For solving it, we just simply add the item SID_ENCRYPTIONDATA
>>  clearing
>> >>> in  SfxobjectShell::PreDoSaveAs_**impl(), similar as the SID_PASSWORD.
>> >>>
>> >>>
>> >> I have reviewed the patch.
>> >> Please see my comments in the issue [1] and [2]
>> >>
>> >> [1] https://issues.apache.org/ooo/**show_bug.cgi?id=119366#c9<
>> https://issues.apache.org/ooo/show_bug.cgi?id=119366#c9>
>> >> [2] https://issues.apache.org/ooo/**show_bug.cgi?id=119366#c11<
>> https://issues.apache.org/ooo/show_bug.cgi?id=119366#c11>
>> >>
>> >>
>> >> Best regards, Oliver.
>> >>
>> >
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message