I am writing a NPAPI plugin, from which i need to access firefox certificate store.
I have included the Gecko SDK and i want to initialize NSS with the default certificate DB.
I am unable to find on how to obtain the certificate DB path programmatically.
I found out the answer. It can be done only using xpcom library. But alternatively, the solution which i use currently is, i read the profile.ini from "%APPDATA%/fozilla/firefox". This file contains the profile directory path for all the profiles created. Also the current profile that is active will contain a property "default=1" . In this way the default path for the certificate DB could be obtained
Related
Am using https://www.pwabuilder.com/ to generate .apk file for uploading to Google Play Store.
Was able to successfully Create New and add PWA for first time to the Play Store, however some updates have been made and now need to update the PWA with latest updates.
For updating a existing app through PWAbuilder, need to change Options:
and for the Signing key section, then need to select the Use mine option:
How to get the Key file for the Signing key section?
and where to find the Key alias + Key password + Key store password?
Am having trouble finding answer specifically for this situation so if you can, please also share screenshots to help be more clear & specific.
Okay so I misunderstood and thought this key file and info is found through the Google Play Console, however when reading issue on https://github.com/pwa-builder/PWABuilder/issues/961 I came across the post by user xet7 and that contains 6 steps and I realized with their step 5:
You will get .zip file that has key file like signing.keystore that has random data, and signingKey-readme.txt that has your passwords.
so I went back to my original .zip received from PWAbuilder website during initial uploading to Google Play and found those two files:
In the signing-key-info.txt you will find the info needed for PWAbuilder's Android Package Options to fill in the Signing key section input fields: Key alias + Key password + Key store password
and the signing.keystore is the file we need for the Key file that needs to be included.
Also, make sure to update App version code and update other fields and can hit DONE button!
Calls to CryptProtectData with flag CRYPTPROTECT_LOCAL_MACHINE fail with error code ERROR_FILE_NOT_FOUND when the user profile is not loaded.
Someone reported this issue here: https://blogs.msdn.microsoft.com/spatdsg/2006/01/04/crypt-calls-failing/
I encounter the same error on Windows 2008 R2 with an iis process running under a specific user. Loading the user profile solves the problem.
Once the profile is present on the disk (C:\Users\account_name), the error does not occur anymore, unless the profile directory is deleted.
Is this an expected behavior or is it a bug?
The API documentation doesn't say that a user profile has to be loaded and I do not see why a profile is required for machine-wide encryption. As a result, this API is totally unusable without a loaded profile.
UPDATE
Further investigations show that the call to CryptProtectData triggers the following actions:
registry query for the key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<sid>\ProfileImagePath to extract the profile path
read of the file <profile path>\AppData\Roaming\Microsoft\Protect\<sid>\Preferred
If the profile key is missing, or the path unusable, the function fails.
However, if the path is simply writable, the required files are created and the call succeeds.
So the API requires at least a writable profile path. The user profile does not have to be loaded when the call occurs, but it has to have been loaded at least once before, for the registry key to exist.
It will try to access the key stores in the user profile, and it will fail because its not loaded. Keys are usually in files, so NTFS permissions can be used to restrict access to users. Read this article for more info. Although machine-level RSA key containers are available to all users, they can be secured with NTFS Access Control Lists (ACLs) so that only required users can access them.
I have gotten the following message from App Store Connect when trying to upload a new version...
Missing Purpose String in Info.plist File - Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSBluetoothPeripheralUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting Spring 2019, all apps submitted to the App Store that access user data will be required to include a purpose string.If you're using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs.
But I do not use bluetooth anywhere in the app (no bluetooth code).
Here are the frameworks I use:
CoreText, QuartzCore, CoreLocation, CoreGraphics, Foundation, UIKit, StoreKit, CoreData, MapKit
Any advice?
Open Info Plist file and press on + sign add new key in info.plist of your project and add this NSBluetoothPeripheralUsageDescription and write value "Explain the reasons for Bluetooth".
FacebookSDK is scanning Bluetooth since v 4.33. This is the description I have picked.
Facebook-SDK v4.34 contains Places Kit which contains Bluetooth scanning. This app isn't scanning/using Bluetooth at all.
My Windows desktop application handles a specific URI scheme, let's call it myscheme:, so URLs like myscheme://what/ever open my app. We set that up by creating a registry key and several values under HKEY_CURRENT_USER\Software\Classes\myscheme. (It's an app that installs per-user without requiring elevation, thus the use of HKEY_CURRENT_USER.)
I would also like to be able to handle http: and https: URLs in a specified subdomain or path, such as http://mysubdomain.example.com/what/ever. Android provides a way to do this; can I do it in Windows?
I don't need a working example (I'm a fairly experienced Windows developer). All I'm looking for, if the capability exists, is a pointer to any relevant registry key or API name/docs on MSDN or elsewhere - I can take it from there. Thanks!
I've been given a task to create a protocol similar to callto:, that - upon clicking on a link with it - would automatically launch an installed aplication.
I followed the microsoft guide on how a scheme should look like.
My scheme looks like this:
HKEY_CLASSES_ROOT
slican
URL Protocol = ""
DefaultIcon (Default) = "C:\Users\Okabe\Desktop\slican\SlicanP.exe,1"
shell
open
command (Default) = "C:\Users\Okabe\Desktop\slican\SlicanP.exe" "%1""
I thought that was all and tested it with
test link
test telephone link
There was no reaction whatsoever. Internet Explorer asked me if I want to search for a program that can open the content and Chrome responded with nothing, as if I clicked javascript:void(0).
How to get that worked?
Thank you for your help!
The registration you show works perfectly fine for me when I try it on Windows 7. The local app I registered in place of SlicanP.exe ran fine when I invoked a slican: URL from the Start | Run menu, and from within the address bar of Windows Explorer. So the registration works.
Do be aware that Internet Explorer runs in a lower integrity security context, so it may not have rights to run local programs. When I tried to click on an HTML link to a slican: URL, or type a slican: URL in the address bar, IE had trouble executing the local app (even after prompting for permission). I had to run IE as an administrator, then the local app ran just fine.
Also, you really should not be creating a HKEY_CLASSES_ROOT\slican key directly. Create a HKEY_CURRENT_USER\Software\Classes\slican (current user only) or HKEY_LOCAL_MACHINE\Software\Classes\slican (all users) instead. Refer to MSDN for more details:
HKEY_CLASSES_ROOT Key
Merged View of HKEY_CLASSES_ROOT
Update: Since it works in Windows 7, Microsoft probably changed how URL schemes are registered in Windows 8. For instance, phone/store apps use URI activation:
URI activation (XAML).
URI activation (HTML)
The documentation says there are two ways to register a custom URI scheme:
Internet Explorer uses two mechanisms for registering new pluggable protocol handlers. The first method is to register a URI scheme name and its associated application so that all attempts to navigate to a URI using that scheme launch the application (for example, registering applications to handle mailto: or news: URIs). The second method uses the Asynchronous Pluggable Protocols API, which allows you to define new protocols by mapping the URI scheme to a class.
You are doing the first. Try using the second instead.
However, I just noticed that "Asynchronous Pluggable Protocols" is listed on MSDN in the "Legacy APIs" section, and it has the following note:
Third-party protocol implementations won't load in Windows Store apps using JavaScript, or in the Internet Explorer in the new Windows UI.
So it may or may not work in Windows 8.
Update: I just found this:
Guidelines for file types and URIs
In Windows 8, the relationship between apps and the file types they support differs from previous versions of Windows.
Walkthrough: using Windows 8 Custom Protocol Activation
The file type and protocol association model has changed in Windows 8. Apps are no longer able to programmatically set themselves as the default handler for a file type or protocol. Instead, now the user always controls what the default handler is for a file type or protocol.
Your app can use existing protocols for communication, such as mailto, or create a custom protocol. The protocol activation extension enables you to define a custom protocol or register to handle an existing protocol.
Also have a look at this:
Setting mailto: protocol handler programmatically in Windows 8
And this:
Default Programs
if you go to C:\Users\\AppData\Local\Google\Chrome\User Data
You can edit the Local State file
Search for protocol_handler
The syntax here is a key value pair. I usually copy two mailto: and make sure that you set your protocols to false. This will mean that chrome will treat your new protocols as URI_Handler events
If you have troubles with configuring custom URI scheme, you can compare your own configuration with existing one. For example, "HKEY_CLASSES_ROOT/mailto" - most likely you have it already in your system.