The problem here is that if you want to support these browsers which are shipped as snaps, they are strictly confined and so won’t be able to execute the interceptor extension since it will be outside of their sandbox. Also would postman-agent want to support users running chromium (whether from the snap or native) - in which case you would also want to support the paths ~/.config/chromium/NativeMessagingHosts/ and ~/snap/chromium/current/.config/chromium/NativeMessagingHosts/? Finally, Firefox may also need to be supported similarly.Įven if you do use either personal-files to access these paths, or classic confinement, postman-agent will only be able to work with browsers that are natively installed (ie you won’t be able to support either the Firefox or Chromium snaps). However, as postman-agent is not the clear owner of this path it likely would not be granted auto-connect to write to this location. If access to the ~/.config/google-chrome/NativeMessagingHosts/ path is all that is required, then this can be achieved via the personal-files interface. Please let me know if any more details are required. The beta and stage variants would be used by the internal team. We request you to allow the classic confinement for these apps: We have registered the following names and want to start testing this capability on them. We wanted to start with making the new postman-agent as classic app and possibly in future do the same for the postman app as well. It also needs to support the same feature interceptor as mentioned above and hence requires the classic confinement. Postman is now supported on browsers and it uses a much slimmer native companion app to send the requests which we call “Postman Agent”. This feature is already working for other platforms where we have this access and even on Linux it is working for the app that we distribute directly from our website (as a tarball) and is broken for the snap variant. We essentially need to access the ~/.config/google-chrome/NativeMessagingHosts/ location to put our manifest file. You can read more about the feature here: We need access the directory where Chrome is installed and put a manifest file there. To do this, it uses Chrome’s Native Messaging feature. We support a feature interceptor using which our users can sync their cookies from their browser (Google Chrome) to our app. If you are still facing problems in starting Postman, feel free to reach out on Twitter or Github.Postman is a tool to help in API Development workflows. You can try disabling experimental web features too but just to be on the safer side, I would suggest resetting everything. So, all you have to do is go to chrome://flags and reset everything to defaults. In r166627 and r166494, we changed CSP 1.1 to block certain CSSOM operations if ‘unsafe-eval’ isn’t present in a ‘style-src’ directive. This seems to be incompatible with the web it broke every site using jQuery, GitHub, etc. The problem seems to be related to this bug: view=revision&revision=167321 and is apparently caused by the “Experimental web platform features” flag. After digging around, I found out that resetting Chrome flags fixed the issue. One of our users was kind enough to let me debug this problem through Team Viewer. The console would show you a bunch of scary errors: On clicking the app icon, the Postman window opens but neither the history data loads nor are requests sent. Some users recently reported that they were unable to start Postman (both packaged and legacy apps) after the new Chrome v34 update.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |