Using native code, I'm able to fetch Passbook passes created by my organization, via PKPassLibrary's passes method.
However, I'd like to be able to do the same via a web page, with no interaction from a native app and without any user information. So far I've only been able to find information about installing passes from the web, as well as information on the web service I must implement.
IE: Using only passTypeIdentifier, organizationName, teamIdentifier and proper certificates, is it possible to query a device for passes installed by my organization without a native app? If so, can I fetch the current pass.json from that pass? Are there any services available that do this?
There is no method available to query a device for passes installed.
Your only chance is to maintain a server-side list of installed passes (easy to do with the register/unregister webservice calls) and some cookie-based registration in mobile safari.
Related
At work we have developed an individual customer specific software application that is in use for a long time. We have a new requirement in this same program to implement an option for sending emails directly from the program.
The user is able to add his own email account with the credentials and login through our program. For Microsoft and Gmail accounts OAUTH is implemented and something here is not very clear.
For Gmail-API we have made an OAUTH Client and Consent screen on Google Cloud Console which we need to publish and verify and here is where the problems start. I am not very clear with the whole process of verifying the app.
In the steps for verifying is stated that we should verify a domain for the app, but this software is not hosted anywhere on internet and is not publicly available, it is available to a number of specific users (2000-3000).
Also Google requires a YouTube video of the software to be available publicly, which we are not able to upload because of customer requirements. Also here is required a Data Protection Policy page for the application which we as a developers don't have because we are only developing the software.
Other thing that is not clear to me, how is this type of software rated by Google, internal or public?
Have anyone experience with this or something similar?
Verifying an app for one of the Gmail scopes is a very complicated process. This process depends upon which scope of authorization you are requesting of the users.
In your case you are trying to send an email so you are using the users.messages.send method from the Gmail api. This uses a restricted scope. Which means you will need to go though the full process.
First of it doesn't matter if your application is hosted or not. It also doesn't matter that you give this app to a limited number of users. What matters is the scopes you are using.
You will need to ensure that your domain has been registered via google search console. So this app will need a domain
Once that is done you will be able to host your website, and the privacy policy on that domain.
You will need to create a YouTube video showing your application running, and how authorization is used.
You will also need to submit to a third party security checkup of your application which is not free and will need to be done once a year.
All of this is needed because of your consent screen it doesn't matter if its hosted any where, It also doesn't matter if this is only available to specific number of users.
If all of the users are part of a single google workspace account, that has created your client id and client secrete then you can set the app to internal and you wont need to be verified. This only works for google workspace domain accounts.
I have a mobile app (React native) that I am using with ParseReact with and have it so the user can immediately send data to parse inside the app. How can I lock this down so that parse.com will only take data from users with the APP installed?
Mitigations I have thought about:
Using ip address, geolocation, deviceUUID (per app)
Possible encrypting traffic to parse to hide something secret?
I know 98% of users will likely be nice and not fake this but I'm worried about the hackers
The short answer is you can't. If you give public access to any of your classes, anyone can write to it and you will have no control on who is reading the data. You can make it difficult for someone to send write requests outside of your app by embedding a signature in your app and forcing all your public writes to go through cloud functions. You use the signature to sign every write request and send the signed token as a parameter to your cloud functions where it will be verified before you accept a request. But remember a cracker can easily find your signature in your app binary so this not bulletproof.
TLDR: All I want to do is secure my cloud function in Parse so that it only accepts requests from my iOS app. How can I do that?
Longer version:
I recently got started with using Parse for a client side app I'm building using a Google API.
Before using Parse, my issue was that the Google API calls from my app were not secure. I tried a Man in the middle attack on my app, and I was able to successfully get the bundle id and app id (Google claims some form of security is achieved by ensuring that the call is from the correct bundle id that you can specify on their console). So despite using SSL, seems like it was easy to get this information. Now this Google API is paid, so someone could easily abuse my key when I release my app and raise my bills.
I was anyways also thinking of doing some lightweight work in the backend, so I figured to use Parse. Now the call to the Google API is done in Cloud Code. But a new problem I'm facing is how to secure calls to the Cloud function I've defined in Parse? The Parse App ID and Client Key aren't secure at all.
All of Parse's blogs keep talking about creating users and defining ACLs etc. But in my case, there is no data in my Parse app and there is no user per se. It simply calls the Google API and returns the result. All I want to do is secure my cloud function so that it only accepts requests from my iOS app. How can I do that?
The inherent security risk here is that any key you store in your app is vulnerable, for that reason encryption is also vulnerable. My recommendation is to use the automatic user in Parse on your iOS app, you could even throttle excessive requests/abuse by a single user. By creating and using a user you are able to gain the benefits of ACL which appears the best security option available in Parse currently. At that point you send the automatic user in your cloud code request and verify it's a valid iOS user.
I would like to play videos inside an IOS web view with Cordova.
Videos must be available only inside this app.
I don't have any domain to restrict access, because it's a web view inside a native app.
Is there a way to use HTTPS with Javascript to authenticate with an API token, then play each video with this token?
Can anyone provide a specific script example to do the job?
It is not possible to do this in such a way that someone could not break it because an attacker could install a man-in-the-middle server with a certificate created using their own certificate authority and then sniff the data and use it outside the application.
However you could make it more difficult, by creating "single use" keys that you send to the device using the notification service every time a key is used, you invalidate it and create a new key for the next use. This would mean that someone trying to get around the system would find it very difficult to have more than one client using the content at any given time.
Given that that is the best you can do, why not simply have users authenticate themselves and not allow multiple sessions to be active for the same user?
We have a web application that supports Facebook and Twitter login/signup via oAuth (and can also post to FB/TW). Now we are building a mobile client and naturally we want people to be able to login-signup via FB-Twitter on mobile as well, on iOS even using system-integrated accounts.
Now mobile app and our server app are two different apps, however, and if I get oAuth correctly, we'll need to have two authentications: one for a mobile client (system account can be used), another one for a server (we'll have to show WebView for it).
Yet some existing apps seem to be fine with single authentication only (e.g. Flickr and Foursquare! At least 4sq seems to be fine with iOS system FB account only. How is it possible?
Do they share consumer key/secret between mobile and web app making it essentially the same app?
Do they use some FB-specific extension to oAuth
Do they only use auth token wherever it comes from making it a user ID?
Something completely different?
Old question, but this may help someone who finds their way here.
Twitter Reverse Auth