Storing CryptoKeys in IndexedDB does not work well. If we store a CryptoKey in IndexedDB we loose the ability to query by index: > QUnit.test('Native', async assert => { > const req = indexedDB.open(dbName, 1); > req.onupgradeneeded = function() { > const db = this.result; > const testStore = db.createObjectStore('test', { autoIncrement: false, keyPath: 'id' }); > testStore.createIndex('id', 'id', { unique: true }); > testStore.createIndex('IDB_class', 'IDB_class', { unique: false }); > }; > await new Promise(r => req.onsuccess = r); > const db = req.result; > const testData = {id: 1, IDB_class: 'test_class', key}; // key is a CryptoKey > tx = db.transaction(['test'], 'readwrite'); > store = tx.objectStore('test'); > store.add(testData); > await new Promise(r => tx.oncomplete = r); > tx = db.transaction(['test'], 'readonly'); > store = tx.objectStore('test'); > const req1 = store.get(1); > await new Promise(r => req1.onsuccess = r); > assert.propEqual(req1.result, testData, 'objects should be equivalent'); > tx = db.transaction(['test'], 'readonly'); > store = tx.objectStore('test'); > const index = store.index('IDB_class'); > const req2 = index.get('test_class'); > await new Promise(r => req2.onsuccess = r); > assert.propEqual(req2.result, testData, 'objects should be equivalent'); > indexedDB.deleteDatabase(dbName); > }); You can test this using this Fiddle: https://fiddle.jshell.net/sechel/qn7oesaf/ Expected behaviour: req1.result and req2.result should be property equivalent to testData. Observed behaviour: Only req1.result is equivalent to testData, req2.result is undefined.
Following up a discussion started in the IndexedDB 2.0 issue: https://bugs.webkit.org/show_bug.cgi?id=160306 > If you can give an example of a real world, in-production site where this > works in other browsers and not WebKit-based ones that could help > reprioritize. You are right, its not high priority as one can create a workaround pretty easy. Just store all WebCrypto keys in a separate object store and resolve the corresponding "foreign keys" in the respective query transaction. On the other hand this has an impact on performance. If there are many keys per object the subsequent resolution of CryptoKeys may be costly. Or is there an even more simple and more effective workaround that I am missing here? We appreciate what has been accomplished with WebCrypto and IndexedDB in the last 12 months. Fixing this issue would just complete the otherwise nice picture. Cheers Stefan
Then again, if one really tries to implement such a workaround further issues start to pop up: https://bugs.webkit.org/show_bug.cgi?id=182972
We have an App that uses WKWebView in the AppStore that is affected by this issue. I changed the architecture up in the meta data to reflect this. Here is a working demo of this issue: https://codepen.io/sechel/pen/VJYqgy
<rdar://problem/75002015>
(In reply to Stefan Sechelmann from comment #3) > We have an App that uses WKWebView in the AppStore that is affected by this > issue. I changed the architecture up in the meta data to reflect this. Here > is a working demo of this issue: https://codepen.io/sechel/pen/VJYqgy We are still failing the test cases here on Safari Technology Preview 179.