There are several ways to send FCM messages and I don't understand which one to use even if I read the documents over and over.
My use case:
I have a user that is logged into the app on her iPhone, iPad and Android tablet. I want to make sure the push notifications are sent to all of her devices.
There are three ways to do this (I'm using the admin to send the push notifications):
Topic messaging (messaging().sendToTopic): My understanding this is for sending the same notification to larger groups. For example a topic could be all users that want weather notifications for New York. Not for my use case.
Send Multicast (messaging().sendMulticast([array of tokens]): My understanding this will send the same message to all device tokens in the array (up to 100). This seems perfect for my use case, right?
Device group messaging (messaging().sendToDeviceGroup): I don't really understand this one. Why use this instead of multicast or topics?
For my use case it seems the best way is to each time a FCM token is updated I add this token to the user in the database. I then send the notification using the admin.messaging().sendMulticast([array of tokens]). Is this what you would recommend? Why or why not?
You probably want to use multicast if you're targeting an individual user's specific devices. You probably don't want to use device groups. I suggest reading the documentation to understand how device groups work:
Device group messaging allows you to add multiple devices to a single group. This is similar to topic messaging, but includes authentication to ensure that group membership is managed only by your servers. For example, if you want to send different messages to different phone models, your servers can add/remove registrations to the appropriate groups and send the appropriate message to each group. Device group messaging differs from topic messaging in that it involves managing device groups from your servers instead of directly within your application.
Device groups are basically just topics whose membership is fully managed by your server code, not by client code.
I'm trying to do some SEO and I want to index the location of an application based on keyword searching. By using the official search API, I've come up with the following query:
https://itunes.apple.com/search?media=software&term=sql+server&limit=&country=us&limit=200
To search the US App Store, for the term sql server. The app I am looking for current shows up in this list at position ~20'th. If I search from my phone, the app is closer to the ~30'th position (other search terms perform even worse). I have tried to use Wireshark to capture the search from my phone to try and see if they use different endpoints, but was unable to capture due to ssl.
Does anyone know of a way to scrape iOS App Store search results in the proper order?
Apple is under no obligation to return search results in any particular order, and is likely to change them depending on client/what search cluster you hit.
Seeing what your phone is sending to the app store is very difficult, however, as Apple takes excessive measures to ensure that communications aren't being read. Last time I tried required BURP Suite, a jailbroken phone, an app to disable SSL pinning, and manually restarting the app store on the phone, which would occasionally crash it.
Set your user agent to replicate an iPhone device browsing the App Store.
Try this one... This is the most recent App Store version, emulating an iPhone X with iOS 11.3.1:
AppStore/3.0 iOS/11.3.1 model/iPhone10,6 hwp/t8015 build/15E302 (6; dt:162)
I was testing my login/sign up feature and for some reason I can't understand Firebase now is blocking all requests from my device.
I've waited one day to try again, but I still have the same problem.
ERROR:
"We have blocked all requests from this device due to unusual activity. Try again later."
What should I do to have access to my database again?
If you use Phone Authentication, Here is what to do:
Go to Firebase Console
Authentication ==> Sign-in-method
Go to "Phone" and pop-up will show
Add your phone number at "Phone Numbers for testing" along with a verification code from your choice.
And it works now :)
One of the possible solutions:
Go to your Firebase console -> Auth -> Users table
Locate the user you are testing.
Delete this user.
Retest.
I contacted firebase support and received this message:
The error "We have blocked all requests from this device due to
unusual activity. Try again later." is usually thrown when a user is
making SMS authentication requests to a certain number of times using
the same phone number or IP address. These repeated requests are
considered as a suspicious behavior which temporarily blocks the
device or IP address.
Additionally, there's a limit of 5 SMS per phone number per 4 hours.
With this, you may try doing the following to resolve the issue:
Reduce the frequency of attempts to avoid triggering the anti-abuse
system Try using whitelisted phone numbers for testing your app
Use multiple testing devices (as the limits are applied per IP or
device) Wait for an hour for the quota to lift
I tried to increase the quota as per #lhk answer but there answer is the
following:
You also mentioned that you have increased the quota to
1000 but it didn't work. Do note that this "Manage to sign up quota"
field is intended for Email/Password and Anonymous sign-ups.
I've run into the same problem.
By default (for the free plan), firebase caps sign-ins to 100 per hour, per IP-address.
This broke our automated testing. You can change the setting like this:
open console
open your project
go to "authentication"
go to "sign-in method"
scroll down to "manage sign-in quota"
That's it. Currently the maximum setting for this quota is 1000 per hour
.
This is one of many quirks that I am running into. While Firebase seems to be a nice framework/product/service, at the moment it doesn't seem to be totally ready for broad production deployment yet. In this case I only used one particular (fake) user for testing/debugging and only after just a few attempts (probably no more than 10 sign-ins), I ran into this issue. The funny thing is that my tests delete the fake test-user after each run so I couldn't see any user in my auth user table afterwards. The solution for me was to manually add that user via the "ADD USER" button and then delete it. I think they should have (at least as a workaround) a definable user that is for testing/debugging, who is not subject to this restriction, if they really feel they have to have such a (low) limit.
I have added my phone as a test number in the Sign-in method tab.
Actually this error occurs when your quota limit is exceeded.
Just add your number and testing OTP to get it worked.
Note: The testing number will not get any message of OTP as we already
defined static OTP code.
See my answer at https://stackoverflow.com/a/39291794/18132
I went into firebase > Authentication > sign-in method > google and added my client id to the whitelist.
I managed to get this working straight away by resetting the users password.
Steps are as follows:
Go into your admin console, Authentication, Users
Locate the user
Click on the menu dots in the far right hand column
Choose reset password, then click ok
Follow the steps in the email when it comes through
The error "We have blocked all requests from this device due to unusual activity. Try again later." is usually thrown when a user is making SMS authentication requests to a certain number of times using the same phone number or IP address. These repeated requests are considered as a suspicious behavior which temporarily blocks the device or IP address.
Additionally, there's a limit of 5 SMS per phone number per 4 hours. With this, you may try doing the following to resolve the issue:
Reduce the frequency of attempts to avoid triggering the anti-abuse system Try using whitelisted phone numbers for testing your app Use multiple testing devices (as the limits are applied per IP or device) Wait for an hour for the quota to lift
Add that number of yours to Firebase as a tester. This way you can test it as many times as you can.
Else multiple requests from one number to a project. Firebase deals it as a hacker and blocks it.
Add your number as Tester as:
Go to
-> Firebase Console -> Authentication -> Sign-in-method -> Edit Phone -> Phone numbers for testing (optional)
Add your phone number and verification code of your choice and that number will then work.
You will not get verification code from firebase, but you can give the verification code you set as a tester and can login through phone
One of the causes can be sending too may verification email to a user's email within a short duration of time. Try adding a duration timer and check if the verification message has been sent within the time duration.
If you are doing tests a better way to go about it is to add the phone number as a test number Authentication > Sign in method > Phone. Then add the test number + the verification code you'll use
I was facing the same issue and I solved this problem by Buying Blaze plan. This blocking seemed like a security measure on Firebase's side.
If you are using Firebase for development purpose, buying the Blaze plan won't cost you any thing as it has the same quota of free services offered in Spark plan.
Also, setting up Firebase Auth test phone numbers should help.
Per https://firebase.google.com/docs/auth/ios/phone-auth#test-with-fictional-phone-numbers:
Test with fictional phone numbers
You can set up fictional phone numbers for development via the Firebase console. Testing with fictional phone numbers provides these benefits:
Test phone number authentication without consuming your usage quota.
Test phone number authentication without sending an actual SMS message.
Run consecutive tests with the same phone number without getting throttled. This minimizes the risk of rejection during App store review process if the reviewer happens to use the same phone number for testing.
Test readily in development environments without any additional effort, such as the ability to develop in an iOS simulator or an Android emulator without Google Play Services.
Write integration tests without being blocked by security checks normally applied on real phone numbers in a production environment.
Fictional phone numbers must meet these requirements:
Make sure you use phone numbers that are indeed fictional, and do not already exist. Firebase Authentication does not allow you to set existing phone numbers used by real users as test numbers.
One option is to use 555 prefixed numbers as US test phone numbers, for example: +1 650-555-3434
Phone numbers have to be correctly formatted for length and other constraints. They will still go through the same validation as a real user's phone number.
You can add up to 10 phone numbers for development.
Use test phone numbers/codes that are hard to guess and change those frequently.
Create fictional phone numbers and verification codes
In the Firebase console, open the Authentication section.
In the Sign in method tab, enable the Phone provider if you haven't already.
Open the Phone numbers for testing accordion menu.
Provide the phone number you want to test, for example: +1 650-555-3434.
Provide the 6-digit verification code for that specific number, for example: 654321.
Add the number. If there's a need, you can delete the phone number and its code by hovering over the corresponding row and clicking the trash icon.
From what I've understood (which could be completly wrong and therefore this post will make no sense), I need to create separate APP Id's in my developer portal for my Watch app/extension.
I did that, and I now have 3 app ID's and their complete related set of provisioning profiles up and running.
The archive works fine and I'm about to submit but, I see that because there is an app ID, I can link a PUSH Certificate (apn). Since the Apple Watch doesn't really get notified, but the phone does, do I really need to create specific certificates for the apple Watch ? And use their related .p12 wherever I would need them (parse.com for example) ?
Or can I simply ignore that and keep the regular phone certificates ?
Thanks
If you already have push notifications set up properly for your iPhone app, they will be delivered to the Watch automatically. You don't need to set up any separate certificates.
Docs: https://developer.apple.com/library/ios/documentation/General/Conceptual/WatchKitProgrammingGuide/BasicSupport.html#//apple_ref/doc/uid/TP40014969-CH18-SW1
Additionally, I have deployed a number of apps already and have first-hand experience.
When an online client (a desktop) and an offline client (a phone) both enter data, and the phone is brought back online, the phone does not receive the data posted on the desktop during the offline period.
To duplicate, in an empty directory, run firebase bootstrap, enter the name of your app, and choose the react template. Then do firebase deploy and firebase open to visit the page in the desktop browser. Then visit the same page in the phone browser.
Begin entering data alternately in the React + Plain Firebase pane of the desktop and phone browsers. Enter '1' on the desktop, '2' on the phone, '3' on the desktop, etc. So far the series displays 1 2 3 on both browsers as expected. Then put the phone in airplane mode and continue entering numbers alternately. Now the desktop shows only the odd numbers that are being added, and the phone shows only the even. This is also expected.
Now bring the phone back online. The phone will push its data to firebase and the even numbers will show up on the desktop (although oddly in a different order in the React + Plain Firebase pane and the React + ReactFire pane).
But the odd numbers do not show up on the phone, until the app is reloaded. Is this expected? Is there a way to force a complete resync in when a client goes online?
UPDATE: Other questions I have seen on firebase offline usage have been about detecting presence, user auth or other more complicated scenarios. My case is simpler. The docs say:
Once connectivity is reestablished, we'll receive the appropriate set of events so that the client "catches up" with the current server state, without having to write any custom code.
To me, this means that syncing should "just work" without the necessity of the app "knowing" whether or not it is online or doing anything special when it goes online.
I was also assuming that firebase offline data storage is persistent, but Kato's recent comment to this question indicates that it is not. So I guess the answer is that Firebase's offline storage implementation is incomplete, and its limitations are not well documented.