I am working on my first Shopify app. While it's not embedded (setting in application settings) it works okay but when I turn it into embedded mode then I get invalid HMAC error.
I searched for different kind of validation for embedded apps but didn't find anything. It seems that it should be the same for usual and embedded apps
UPDATE (with solution):
the embedded app adds one additional param:
protocol=https://
This additional param must be included in HMAC calculation (in case it is embedded app). Important thing that this param MUST BE NOT ENCODED when you pass this param for HMAC calculation.
Related
First of all this is my 1st stackoverflow post so sorry if I am missing context or do if the question is too out of the ordinary.. Onto some context and example use case for my question.
Context
I'm making a simple app for an uni assignment in React-Native but one of the requirements client we are making it for is that the text (copy) in the app can be adjusted by him after we deliver it to him.
Example Use Case
They want to change the text on the welcome screen from "Welcome, [Name]" to "Hello there, [Name]". But they aren't technical so they expect to be able to change this in a simple UI.
I've tried googling for solutions but keep finding Localization solutions instead and all I've found so far require in-code edits.
Example:
🌍 react-native-localize & Expo Localization Docs
Any help/pointers are much appreciated!
There are two basic ways to solve this issue.
Create an API that the app calls to get the text. Make web or app tools for the client to edit the text in the API. This is usually called a CMS (content-management solution). There are a huge range of options, including building your own.
Pros:
the client can maybe manage their own content without intervention... sometimes
content changes are "instant" - without an app release
Cons:
non-trivial to plan and set up
requires support/maintenance
additional costs for hosting
additional app complexity (need to think about error states, caching, polling?)
app NEEDS to be online to have content
OR
The client submits a ticket for the text changes and a developer makes them.
Pros:
doesn't require the creation/ maintenance of additional tools
app doesn't need to make network requests for content
Cons:
changes take longer and require a new release of the app
My aim is to select some text from a web page, start a google chrome extension and give the text to a google cloud api (Natural Language API) in my case.
I want to do some sentimental analysis and then get back the result to mark/ highlight positive sentences in green and negative ones in red.
I am new to this and do not know how to start.
The extension consists of manifest, popup etc. How should I call an API from there that does Natural Language Processing?
Should I create a Google Cloud Application with an API_KEY to call? In that case I would have to upload my credentials right?
Sorry sounds a bit confusing I know but I just don't know how I can bring this 2 things together an would be more than happy about any help
The best way to authenticate your app will depend on the specific needs and use cases of your application. You can see an overview of all the different methods here.
If you are not planning on identifying users nor on using a back end server that handles authenticating (as I assume to be your case), the best option would indeed be to use API keys. They do not identify the user, but are enough for the Natural Language APIs.
To do this you will need to create an API key for the services you want and add the necessary restrictions to make the key as secure as possible. Detailed instructions on how to do this and how to use the key in a url can be found here.
The API call could be made from within the Chrome extension with any JavaScript method capable of performing POST requests. For example using XMLHttpRequest or the Fetch API. You can find an example of the parameters that need to be included in the request here.
You may run into CORS issues when making the request directly from the extension. I recommend reading this answer, where a couple of workarounds for these issues are suggested.
I am very puzzled by a situation here. Basically, i have an branch link with 2 parameters. In my iOS, it is handled in the deeplinkhandler setup during the setup.
However, the link works VERY differently. We installed on the TF on our phones. The app store does not have the version w branch yet.
configuration below:
from both of our chrome: works seamlessly, deeplinked works
from my phone, iMessage: goes to appstore
from his phone, iMessage: goes to app but deep linking does not work
so.....
if it works on chrome, does that mean my integration is done right?
why would it work differently from my phone and another phone, given we have the same OS?
if the main goal is to deeplink properly (like emails), wouldn't it be more effective to do a URL scheme, where we know for certain that the deep link will land ther user where we need?
EDIT: Figured out part of the problem: my device was "disabled for universal links"
Now, it is because continue userActivity is not being called even when the link appears to work! I know because it does not show up in my debug logs, AND when i initialized the app WHEN the deeplink DOES not appear to work, the deeplink is triggered when I open the app. :)
// This is my method signature, its in an appdelegate EXTENSION.
// could that be the problem?
// i am using swift 2.3
func application(application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: ([Any]?) -> Void) -> Bool {
application.fuckingComprehensivePrint("application continue in appdelegate")
return Branch.getInstance().continueUserActivity(userActivity)
}
EDIT 2: Ok, so all in all, there were THREE problems
My device was disabled for universal links
I put my method signature in an extension
My method signature was wrong (i used swift 3.0 syntax)
I also had URL handling in my app (separate from branch) that caused it to work in some instances.
Alex from Branch here: welcome to the crazy world of deep linking — this is why Branch exists :).
To answer your questions:
If things are working correctly in Chrome, it means your implementation is at least partially correct. This is because in some situations Branch can still use a URI scheme redirect with Chrome. If this is the case, your app will open without the 'forward to web' arrow in the top right corner (this is the giveaway that you were just Universal Linked). Based on what you're describing (Chrome deep links, but iMessage doesn't), it sounds like your openURL method (URI scheme links) is correctly configured but continueUserActivity (Universal Links) isn't.
Since behavior is different on identical devices, I suspect Universal Links on your device may have become disabled at some point during testing. This is very easy to do — thanks, Apple — but also fairly easy to fix: just paste the link into the iOS Notes app, long-press (not force-press) on the link, and then select Open in [app].
Up until iOS 9, URI schemes were the de facto best option. With Universal Links, and the changes Apple has imposed to force their adoption, URI schemes are an increasingly bad user experience (scary error messages, no fallback ability, etc.). You can read about this in greater detail in this blog post. Plain vanilla URI scheme deep links also cannot work when the app isn't yet installed, and many apps don't recognize them as valid, clickable links so they need to be wrapped inside a regular http link with a redirect.
Branch is a fundamentally different approach to content linking in apps.
Rather than standard links with paths to content, you can think of Branch links as unique tokens that deliver an unlimited number of key:value pairs to you in the app (including — if you really want it — a URI path that can be automatically triggered), in exactly the same way, in every situation.
So rather than needing to handle all the different and constantly-changing standards, trying to detect whether the app is installed when a link is clicked, worrying about which app or browser the user might be using to open the link, etc., all you need to do is wait for the link keys to be delivered. Branch has abstracted all of these technical details out into a separate framework.
It's conceptually different at first, but far more flexible because you're no longer limited to just the data that can be stored in a URI path.
I need my native iPad application to store its data (say .DOC documents downloaded via HTTPS) in an encrypted form. Those .DOC files are to be opened in 3rd party apps on the iPad.
I need to know whether there is a way that data of both my application and those of 3rd party apps can be encrypted? Meaning that my .DOC file will never be stored in unencrypted form on the device. (motivation here being that my app downloads documents with sensitive information and I want those documents to be read on the iPad, but with the layer of disk-encryption protection.)
I was reading through Advanced App Tricks # apple.com, section "Protecting Data Using On-Disk Encryption", but was unable to find any relevant information.
First, let's get the hardware encryption aspect out of the way:
iOS supports hardware encrpytion of everything on the disk. It's encrypted with a key that has nothing to do with your device pass code. This feature is there to allow quick wiping of the device's data (by overwriting the device encryption key). It doesn't really protect your data from being retrieved by a skilled interloper who can get your device, however; a jailbreak will get around this.
Per-file encryption via the Data Protection API: iOS can be told that certain files are to be encrypted by setting a flag on them. They are then encrypted using the device pass code (if one has been set). Note: if the user hasn't set a passcode, this extra protection isn't applied! Therefore, technically, this protection is out of your control, unless your users work at an organisation that enforces passcode lock policies (using iPhone Configuration Utility or similar).
Encryption using CommonCrypto: you can use encryption APIs such as this to manually do your own encryption/decryption. Note that if you don't know what you're doing it's easily to abuse such APIs and end up with not very secure encryption. However, there are some wrappers such as RNCryptor which make it much harder to abuse these APIs.
Protecting files used by third party apps: Can you clarify how your app will share files with third party apps please?
More info:
http://support.apple.com/kb/HT4175
http://www.ilounge.com/index.php/articles/comments/ios-encryption-and-data-protection/
http://developer.apple.com/library/ios/#documentation/security/Conceptual/cryptoservices/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011172-CH1-SW1
https://github.com/rnapier/RNCryptor
Update
On using UIDocumentInteractionController:
Once you've handed off your document to another app using this method, the data is out of your hands and the third party app can do what it likes with it. If you're happy with that, and your main concern is just having the document stored on your device in a protected way, then there are a couple of possibilities:
Rely on Data Protection API to protect the document on-disk (user has to set a passcode and you need to tell iOS that the particular file is to be protected for this to work)
Using the NSURLProtocol trick mentioned here to decrypt an encrypted file on disk on-the-fly
I've been looking around at various APIs, and since twitter seems to be a common discussion point, I'll use it as an example.
A lot of APIs are implementing oAuth which is great for allowing the service to authenicate and authorize the application connecting to it, however, from what I have seen there doesnt seem to be a way for the application to verify that Twitter is actually Twitter (and not a man in the middle based attack)? I would expect to see some kind of signature (using a shared / public key) of the response body which I can use to validate that twitter signed it.
Is it just because currently there isnt really a point to a man in the middle attack with twitter tweets since currently, whats the worst that can happen (and why would someone want to give me invalid tweets)
On this point, if you were to sign the response, what method would you use? Im currently considering a HMAC-SHA1 signature of the response body using a shared key.
This is what the 'trust' part of SSL does.
-- Edit
I note this has been downvoted, but it's important that other readers realise it's due to a personal disagreement, not due to incorrectness.
In the .NET world we use WCF, which has many different security models, including signing (and if desired encrypting) each message/response. This adds up to a non-trivial amount of overhead, but can give you more 'trust' in the security model. You can switch to using binary-serialized data to cut down on the bloat and message size if you desire.
I'm not sure what other Web Service APIs offer in that area, though I'm sure someone else can add further details as needed.