1 /*
2  objecttreeparser.h
4  This file is part of KMail, the KDE mail client.
5  SPDX-FileCopyrightText: 2003 Marc Mutz <[email protected]>
6  SPDX-FileCopyrightText: 2002-2003, 2009 Klarälvdalens Datakonsult AB, a KDAB Group company, [email protected]
7  SPDX-FileCopyrightText: 2009 Andras Mantia <[email protected]>
9  SPDX-License-Identifier: GPL-2.0-or-later
10 */
12 #pragma once
14 #include "mimetreeparser_export.h"
16 #include "mimetreeparser/nodehelper.h"
17 #include "mimetreeparser/objecttreesource.h"
19 #include <gpgme++/verificationresult.h>
21 class QString;
23 namespace KMime
24 {
25 class Content;
26 }
28 namespace MimeTreeParser
29 {
30 class PartMetaData;
31 class ViewerPrivate;
32 class NodeHelper;
33 class MessagePart;
34 class MimeMessagePart;
36 typedef QSharedPointer<MessagePart> MessagePartPtr;
37 typedef QSharedPointer<MimeMessagePart> MimeMessagePartPtr;
38 /**
39  * @brief The ProcessResult class
40  */
41 class MIMETREEPARSER_EXPORT ProcessResult
42 {
43 public:
44  explicit ProcessResult(NodeHelper *nodeHelper,
45  KMMsgSignatureState inlineSignatureState = KMMsgNotSigned,
46  KMMsgEncryptionState inlineEncryptionState = KMMsgNotEncrypted,
47  bool neverDisplayInline = false)
48  : mInlineSignatureState(inlineSignatureState)
49  , mInlineEncryptionState(inlineEncryptionState)
50  , mNeverDisplayInline(neverDisplayInline)
51  , mNodeHelper(nodeHelper)
52  {
53  }
55  Q_REQUIRED_RESULT KMMsgSignatureState inlineSignatureState() const;
56  void setInlineSignatureState(KMMsgSignatureState state);
58  Q_REQUIRED_RESULT KMMsgEncryptionState inlineEncryptionState() const;
59  void setInlineEncryptionState(KMMsgEncryptionState state);
61  Q_REQUIRED_RESULT bool neverDisplayInline() const;
62  void setNeverDisplayInline(bool display);
64  void adjustCryptoStatesOfNode(const KMime::Content *node) const;
66 private:
67  KMMsgSignatureState mInlineSignatureState;
68  KMMsgEncryptionState mInlineEncryptionState;
69  bool mNeverDisplayInline : 1;
70  NodeHelper *mNodeHelper;
71 };
73 /**
74 \brief Parses messages and generates HTML display code out of them
76 \par Introduction
78 First, have a look at the documentation in Mainpage.dox and at the documentation of ViewerPrivate
79 to understand the broader picture.
81 Just a note on the terminology: 'Node' refers to a MIME part here, which in KMime is a
82 KMime::Content.
84 \par Basics
86 The ObjectTreeParser basically has two modes: Generating the HTML code for the Viewer, or only
87 extracting the plainTextContent() for situations where only the message text is needed, for example
88 when inline forwarding a message. The mode depends on the Interface::ObjectTreeSource passed to the
89 constructor: If Interface::ObjectTreeSource::htmlWriter() is not 0, then the HTML code generation mode is
90 used.
92 Basically, all the ObjectTreeParser does is going through the tree of MIME parts and operating on
93 those nodes. Operating here means creating the HTML code for the node or extracting the textual
94 content from it. This process is started with parseObjectTree(), where we loop over the subnodes
95 of the current root node. For each of those subnodes, we try to find a BodyPartFormatter that can
96 handle the type of the node. This can either be an internal function, such as
97 processMultiPartAlternativeSubtype() or processTextHtmlSubtype(), or it can be an external plugin.
98 More on external plugins later. When no matching formatter is found, defaultHandling() is called
99 for that node.
101 \par Multipart Nodes
103 Those nodes that are of type multipart have subnodes. If one of those children needs to be
104 processed normally, the processMultipartXXX() functions call stdChildHandling() for the node that
105 should be handled normally. stdChildHandling() creates its own ObjectTreeParser, which is a clone
106 of the current ObjectTreeParser, and processes the node. stdChildHandling() is not called for all
107 children of the multipart node, for example processMultiPartAlternativeSubtype() only calls it on
108 one of the children, as the other one doesn't need to be displayed. Similarly,
109 processMultiPartSignedSubtype() doesn't call stdChildHandling() for the signature node, only for the
110 signed node.
112 \par Processed and Unprocessed Nodes
114 When a BodyPartFormatter has finished processing a node, it is processed. Nodes are set to being
115 not processed at the beginning of parseObjectTree(). The processed state of a node is saved in a
116 list in NodeHelper, see NodeHelper::setNodeProcessed(), NodeHelper::nodeProcessed() and the other
117 related helper functions.
119 It is the responsibility of the BodyPartFormatter to correctly call setNodeProcessed() and the
120 related functions. This is important so that processing the same node twice can be prevented. The
121 check that prevents duplicate processing is in parseObjectTree().
123 An example where duplicate processing would happen if we didn't check for it is in stdChildHandling(),
124 which is for example called from processMultiPartAlternativeSubtype(). Let's say the setting is to
125 prefer HTML over plain text. In this case, processMultiPartAlternativeSubtype() would call
126 stdChildHandling() on the HTML node, which would create a new ObjectTreeParser and call
127 parseObjectTree() on it. parseObjectTree() processes the node and all its siblings, and one of the
128 siblings is the plain text node, which shouldn't be processed! Therefore
129 processMultiPartAlternativeSubtype() sets the plain text node as been processed already.
131 \par Plain Text Output
133 Various nodes have plain text that should be displayed. This plain text is usually processed though
134 writeBodyString() first. That method checks if the provided text is an inline PGP text and decrypts
135 it if necessary. It also pushes the text through quotedHTML(), which does a number of things like
136 coloring quoted lines or detecting links and creating real link tags for them.
138 \par Modifying the Message
140 The ObjectTreeParser does not only parse its message, in some circumstances it also modifies it
141 before displaying. This is for example the case when displaying a decrypted message: The original
142 message only contains a binary blob of crypto data, and processMultiPartEncryptedSubtype() decrypts
143 that blob. After decryption, the current node is replaced with the decrypted node, which happens
144 in insertAndParseNewChildNode().
146 \par Crypto Operations
148 For signature and decryption handling, there are functions which help with generating the HTML code
149 for the signature header and footer. These are writeDeferredDecryptionBlock(), writeSigstatFooter()
150 and writeSigstatHeader(). As the name writeDeferredDecryptionBlock() suggests, a setting can cause
151 the message to not be decrypted unless the user clicks a link. Whether the message should be
152 decrypted or not can be controlled by Interface::ObjectTreeSource::decryptMessage(). When the user clicks the
153 decryption link, the URLHandler for 'kmail:' URLs sets that variable to true and triggers an update
154 of the Viewer, which will cause parseObjectTree() to be called again.
156 \par Async Crypto Operations
158 The above case describes decryption the message in place. However, decryption and also verifying of
159 the signature can take a long time, so synchronous decryption and verifying would cause the Viewer to
160 block. Therefore it is possible to run these operations in async mode, see allowAsync().
161 In the first run of the async mode, all the ObjectTreeParser does is starting the decrypt or the
162 verify job, and informing the user that the operation is in progress with
163 writeDecryptionInProgressBlock() or with writeSigstatHeader(). Then, it creates and associates a
164 BodyPartMemento with the current node, for example a VerifyDetachedBodyPartMemento. Each node can
165 have multiple mementos associated with it, which are differeniated by name.
167 NodeHelper::setBodyPartMemento() and NodeHelper::bodyPartMemento() provide means to store and
168 retrieve these mementos. A memento is basically a thin wrapper around the crypto job, it stores the
169 job pointer, the job input data and the job result. Mementos can be used for any async situation,
170 not just for crypto jobs, but I'll describe crypto jobs here.
172 So in the first run of decrypting or verifying a message, the BodyPartFormatter only starts the
173 crypto job, creates the BodyPartMemento and writes the HTML code that tells the user that the
174 operation is in progress. parseObjectTree() thus finishes without waiting for anything, and the
175 message is displayed.
177 At some point, the crypto jobs then finish, which will cause slotResult() of the BodyPartMemento
178 to be called. slotResult() then saves the result to some member variable and calls
179 BodyPartMemento::notify(), which in the end will trigger an update of the Viewer. That update
180 will, in ViewerPrivate::parseMsg(), create a new ObjectTreeParser and call parseObjectTree() on it.
181 This is where the second run begins.
183 The functions that deal with decrypting of verifying, like processMultiPartSignedSubtype() or
184 processMultiPartEncryptedSubtype() will look if they find a BodyPartMemento that is associated with
185 the current node. Now it finds that memento, since it was created in the first run. It checks if the
186 memento's job has finished, and if so, the result can be written out (either the decrypted data or
187 the verified signature).
189 When dealing with encrypted nodes, new nodes are created with the decrypted data. It is important to
190 note that the original MIME tree is never modified, and remains the same as the original one. The method
191 createAndParseTempNode is called with the newly decrypted data, and it generates a new temporary node to
192 store the decrypted data. When these nodes are created, it is important to keep track of them as otherwise
193 some mementos that are added to the newly created temporary nodes will be constantly regenerated. As the
194 regeneration triggers a viewer update when complete, it results in an infinite refresh loop. The function
195 NodeHelper::linkAsPermanentDecrypted will create a link between the newly created node and the original parent.
196 Conversely, the function NodeHelper::attachExtraContent will create a link in the other direction, from the parent
197 node to the newly created temporary node.
199 When generating some mementos for nodes that may be temporary nodes (for example, contact photo mementos), the
200 function NodeHelper::setBodyPartMementoForPermanentParent is used. This will save the given body part memento for
201 the closest found permanent parent node, rather than the transient node itself. Then when checking for the existence
202 of a certain memento in a node, NodeHelper::findPermanentParentBodyPartMemento will check to see if any parent of the
203 given temporary node is a permanent (encrypted) node that has been used to generate the asked-for node.
205 To conclude: For async operations, parseObjectTree() is called twice: The first call starts the
206 crypto operation and creates the BodyPartMemento, the second calls sees that the BodyPartMemento is
207 there and can use its result for writing out the HTML.
209 \par PartMetaData and ProcessResult
211 For crypto operations, the class PartMetaData is used a lot, mainly to pass around info about the
212 crypto state of a node. A PartMetaData can also be associated with a node by using
213 NodeHelper::setPartMetaData(). The only user of that however is MessageAnalyzer::processPart() of
214 the Nepomuk E-Mail Feeder, which also uses the ObjectTreeParser to analyze the message.
216 You'll notice that a ProcessResult is passed to each formatter. The formatter is supposed to modify
217 the ProcessResult to tell the callers something about the state of the nodes that were processed.
218 One example for its use is to tell the caller about the crypto state of the node.
220 \par BodyPartFormatter Plugins
222 As mentioned way earlier, BodyPartFormatter can either be plugins or be internal. bodypartformatter.cpp
223 contains some trickery so that the processXXX() methods of the ObjectTreeParser are called from
224 a BodyPartFormatter associated with them, see the CREATE_BODY_PART_FORMATTER macro.
226 The BodyPartFormatter code is work in progress, it was supposed to be refactored, but that has not
227 yet happened at the time of writing. Therefore the code can seem a bit chaotic.
229 External plugins are loaded with loadPlugins() in bodypartformatterfactory.cpp. External plugins
230 can only use the classes in the interfaces/ directory, they include BodyPart, BodyPartMemento,
231 BodyPartFormatterPlugin, BodyPartFormatter, BodyPartURLHandler and URLHandler. Therefore
232 external plugins have powerful capabilities, which are needed for example in the iCal formatter or
233 in the vCard formatter.
235 \par Special HTML tags
237 As also mentioned in the documentation of ViewerPrivate, the ObjectTreeParser writes out special
238 links that are only understood by the viewer, for example 'kmail:' URLs or 'attachment:' URLs.
239 Also, some special HTML tags are created, which the Viewer later uses for post-processing. For
240 example a div with the id 'attachmentInjectionPoint', or a div with the id 'attachmentDiv', which
241 is used to mark an attachment in the body with a yellow border when the user clicks the attachment
242 in the header. Finally, parseObjectTree() creates an anchor with the id 'att%1', which is used in
243 the Viewer to scroll to the attachment.
244 */
245 class MIMETREEPARSER_EXPORT ObjectTreeParser
246 {
247  /**
248  * @internal
249  * Copies the context of @p other, but not it's rawDecryptedBody, plainTextContent or htmlContent.
250  */
251  ObjectTreeParser(const ObjectTreeParser &other);
253 public:
254  explicit ObjectTreeParser(Interface::ObjectTreeSource *source, NodeHelper *nodeHelper = nullptr);
256  explicit ObjectTreeParser(const ObjectTreeParser *topLevelParser);
257  virtual ~ObjectTreeParser();
259  void setAllowAsync(bool allow);
260  bool allowAsync() const;
262  bool hasPendingAsyncJobs() const;
264  /**
265  * The text of the message, ie. what would appear in the
266  * composer's text editor if this was edited or replied to.
267  * This is usually the content of the first text/plain MIME part.
268  */
269  QString plainTextContent() const;
271  /**
272  * Similar to plainTextContent(), but returns the HTML source of the first text/html MIME part.
273  *
274  * Not to be confused with the HTML code that the message viewer widget displays, that HTML
275  * is written out by htmlWriter() and a totally different pair of shoes.
276  */
277  QString htmlContent() const;
279  /**
280  * The original charset of MIME part the plain text was extracted from.
281  *
282  * If there were more than one text/plain MIME parts in the mail, the this is the charset
283  * of the last MIME part processed.
284  */
285  QByteArray plainTextContentCharset() const;
286  QByteArray htmlContentCharset() const;
288  NodeHelper *nodeHelper() const;
290  /** Parse beginning at a given node and recursively parsing
291  the children of that node and it's next sibling. */
292  void parseObjectTree(KMime::Content *node, bool parseOnlySingleNode = false);
293  MessagePartPtr parsedPart() const;
295 private:
296  void extractNodeInfos(KMime::Content *curNode, bool isFirstTextPart);
297  void setPlainTextContent(const QString &plainTextContent);
299  /**
300  * Does the actual work for parseObjectTree. Unlike parseObjectTree(), this does not change the
301  * top-level content.
302  */
303  MessagePartPtr parseObjectTreeInternal(KMime::Content *node, bool mOnlyOneMimePart);
304  MessagePartPtr processType(KMime::Content *node, MimeTreeParser::ProcessResult &processResult, const QByteArray &mimeType);
306 private:
307  /** ctor helper */
308  void init();
310  const QTextCodec *codecFor(KMime::Content *node) const;
312 private:
314  NodeHelper *mNodeHelper;
315  QByteArray mPlainTextContentCharset;
316  QByteArray mHtmlContentCharset;
317  QString mPlainTextContent;
318  QString mHtmlContent;
319  KMime::Content *mTopLevelContent = nullptr;
320  MessagePartPtr mParsedPart;
322  /// Show only one mime part means that the user has selected some node in the message structure
323  /// viewer that is not the root, which means the user wants to only see the selected node and its
324  /// children. If that is the case, this variable is set to true.
325  /// The code needs to behave differently if this is set. For example, it should not process the
326  /// siblings. Also, consider inline images: Normally, those nodes are completely hidden, as the
327  /// HTML node embeds them. However, when showing only the node of the image, one has to show them,
328  /// as their is no HTML node in which they are displayed. There are many more cases where this
329  /// variable needs to be obeyed.
330  /// This variable is set to false again when processing the children in stdChildHandling(), as
331  /// the children can be completely displayed again.
332  bool mShowOnlyOneMimePart;
334  bool mHasPendingAsyncJobs = false;
335  bool mAllowAsync;
336  // DataUrl Icons cache
337  QString mCollapseIcon;
338  QString mExpandIcon;
339  bool mDeleteNodeHelper;
341  friend class PartNodeBodyPart;
342  friend class MessagePart;
343  friend class EncryptedMessagePart;
344  friend class SignedMessagePart;
345  friend class TextMessagePart;
346  friend class HtmlMessagePart;
347  friend class MultiPartSignedBodyPartFormatter;
348  friend class ApplicationPkcs7MimeBodyPartFormatter;
349 };
350 }
an implementation of the BodyPart interface using KMime::Content&#39;s
QCA_EXPORT void init()
Interface for object tree sources.
Parses messages and generates HTML display code out of them.
The ProcessResult class.
This file is part of the KDE documentation.
Documentation copyright © 1996-2021 The KDE developers.
Generated on Thu Apr 22 2021 23:14:31 by doxygen 1.8.11 written by Dimitri van Heesch, © 1997-2006

KDE's Doxygen guidelines are available online.