At least PDF may be password protected (I don't know about the other formats). As of now, every time one opens one single protected PDF one is asked for the password. I propose okular saves the password for future use.
Hi Arian, do you have kwallet enabled? This should already be possible according to bug 218806.
Yeah we already do that
If you can provide the information requested in comment #1, please add it.
To further investigate this issue, KDE developers need the information requested in comment #1. If you can provide it, or need help with finding that information, please add a comment.
No response, changing status. If you have more information, please add a comment.
Created attachment 90957 [details] Workaround patch to allow access to KWallet
I also suffer the same issue. But I have 2 systems, one where passwords are being saved, and another where passwords are not being saved. Here are the system details: Okular 0.19.3 / KDE 4.13.3 - allows for storage / retrieve in KWallet Okular 0.20.0 / KDE 4.14.1 - does not store / retrieve from KWallet origin/master (v14.12.2-18-g24006bb) also fails in the same way On both system, I do have KWallet enabled, and it is working. Doing some debug, here is my analysis: - KWallet will be used in Part::doOpenFile if walletKey.isNull() != NULL (in my case it is NULL) - walletKey should be setup by m_document->walletDataForFile() - In Document::walletDataForFile, d->m_generator == NULL, so nothing gets set - Rolling back the anaylsis... - Before m_document->walletDataForFile() is called, m_document->openDocument() will be called - Document::openDocument() calls d->openDocumentInternal() - DocumentPrivate::openDocumentInternal() does setup m_generator, but as DocumentPrivate::openDocumentInternal() can't open the file (it is password protected, but we don't have a valid password yet), this routine will fail - as part of the cleanup during failure processing, DocumentPrivate::openDocumentInternal() will set m_generator = 0, but it is this m_generator that is required later to access KWallet I have coded the one line code change to remove setting 'm_generator = 0;' and okular / KWallet integration is working correctly. I've added my patch to work-around (fix?) the issue. But, what are the implications of removing 'm_generator = 0;' from DocumentPrivate::openDocumentInternal() ? Though it does solve the immediate problem - but are there other issues that could be introduced ?
I am finding it difficult to use Okular to open a locked PDF from my university. We use these files for sharing textbooks, and I need to be able to unlock it on my desktop. While I can use the web viewer from my online college, this can be rather tedious and it would be preferable to use the login/password protocols that exist within the document. I cannot even use the forms to do this. I am new to Linux, and will need to learn how to open up KWallet. Even so, being able to open this document in the first place will be a big help.
Git commit 10a1899058898eeacc4e3064506825634d2c07ad by Albert Astals Cid. Committed on 09/02/2015 at 21:03. Pushed by aacid into branch 'Applications/14.12'. Hack to restore KWallet support Better fix code-wise will come with an API break in master M +6 -0 core/document.cpp M +2 -0 core/document_p.h http://commits.kde.org/okular/10a1899058898eeacc4e3064506825634d2c07ad
Albert - works a dream. Thanks, MarkW
Thanks for your analysis :)