I'd like to know what best practices and approach to get Laravel to work in giving realtime updates. My use case is a service aggregator app where users can request the nearest service provider based on his/her current location and available(online) providers receives the request and whoever accepts get assigned. Similar to Uber's ride request.
Implementing this in firebase using firebase database is pretty much easy but considering that i have my app's backend in Laravel, how do i achieve the same feature where i can synchronise and update location in realtime between the app and backend.
I have read that i could use pusher and/or socket.io but i need proper pointers on how to go about this implementation.
Related
I am attempting to connect a Google Assistant app using DialogFlow(Api.AI) with Firebase Auth. My App uses Firebase Auth to maintain user accounts and the realtime database to store data. I would like to be able to make changes to a user's data through the Google Assistant, maybe using something like a cloud function. In order to make any user changes through Google Assistant, I need to link the user's Google Assistant account with their Firebase Auth account. The current mechanism appears to be using an OAuth flow documented here.
The question I have is, what is the best way to accomplish this? Do I need to set up a custom OAuth server? There is a lot of documentation on Google's cloud website about OAuth, but it all appears to be related to using OAuth to access Google's APIs, and I can't really see a simple way to host this linking mechanism in GCP.
There is this question that is pretty close, but the difference I have is that I don't have an external API, I just want to authenticate my user and be able to modify their data in the realtime database.
Thank you for your help!
here is an example: https://github.com/malikasinger1/Quiz-Assistant
i have done it myself with following best practices,
feel free to comment if you don't understand something.
I have an iOS app and I'm using Firebase as my database.
I know a little about Firebase rules for saving data but i don't have users in my app so i just want to know -
Does Firebase encrypt or hash or secure the transaction between my app and the database?
I don't want some hacker to just easily intercept my call to Firebase and change something and my database will be updated with the wrong information.
Anybody knows the answer to that or how to do that if Firebase doesn't do it automatically?
Thank you
Traffic between your app and the Firebase database always goes over HTTPS, so in general is quite well secured.
But if you don't use authentication and security rules in your app, all a malicious user has to know is the URL of your database (https://yourapp.firebaseio.com) to be able to wreak havoc. This is the nature of a cloud-hosted service: since every client needs to have access to the service, you have to assume malicious users will also have access to the service.
For more on this, see:
How to prevent other access to my firebase
How to make firebase storage only available to users of the app
Swift: Firebase: How to ensure no one can access my db except my app
In Web API, use the nearbySearch function will return the results nearby the specific coordinate.
But I cannot find a similar function in iOS SDK.
I think the worst way is using REST API likes
https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=22.979468,112.544345&radius=100&key=API_KEY by Alamofire
But I have another problem, I don't know how to restrict my API key for iOS REST API only.
I tried to set it for iOS Application but it does not work.
Please give me some idea, thank you very much!
You cannot apply iOS app restriction on web service API key. The only supported restrictions for web services are IP address restrictions. This supposes that you are executing web service requests from your backend server and restrict an API key with IP address of your backend server.
In case of mobile iOS app that means you should create an intermediate server to execute web services and pass responses back to your app in order to protect an API key that you use with web service.
There is a feature request in the Google issue tracker to add nearby search as a part of Places API for iOS:
https://issuetracker.google.com/issues/35830334
Feel free to star this feature request to add your vote and subscribe to further notifications from Google.
Hope this resolves your doubt.
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'm trying to work out the best architecture for a couple of apps I'm developing.
In both apps I want to utilise google/twitter/LinkedIn/etc to provide authentication of a users identity. The app is composed of an iOS app which has an option to send data to a server which I'm writing in node.js.
I want to utilise either OAuth or OpenId to handle identifying a user against the above servers so that I don't have to put in an authentication system of my own. In other words, allowing users to re-use their ids when choosing to upload data.
I should also note that apart from identifying a user, obtaining a name and email address, I have not intention of using any of their APIs at this time.
I think I have two options:
Place the Authorisation code in the iOS client and transmit some sort of key to the server with the data which it can then verify.
Keep the iOS client fairly dumb, and handle authorisation from the node server.
I'd probably prefer the second option because it means I could centralise authentication and be able to support a web site as well. That's my current theory.
Can anyone who has done something like this give me some pointers as to the pros and cons, OAuth or OpenId, or links to some examples?
In our previous app we opted for a combination of the two approaches. We wanted to centralize our user data on our server in the event we needed to make future API calls on those services. We also wanted the native oAuth experience for the user on the client. Ie: on Android and iOS, the developer can have single sign-on / authorization run through the native Facebook app (if available), vs. popping-up a webview that serves the 'Approve' dialog. It's a better user experience in my opinion. Also for Twitter, the oAuth process may require a PIN code to be entered in the callback which should probably be handled on the client side.
You can pass the access token retrieved by the client to the server for storage and later use if you intend on making additional API calls on these services, provided you expect the token to be long-lived (ie: offline-access permission on FB).
In any case this is mostly a user experience decision.