Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add FCM HTTP V1 service #171

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

Add FCM HTTP V1 service #171

wants to merge 10 commits into from

Conversation

dragermrb
Copy link

Add service to use FCM HTTP v1 API.

According to Google (https://firebase.google.com/docs/cloud-messaging/migrate-v1)

Apps using the deprecated FCM legacy APIs for HTTP and XMPP should migrate to the HTTP v1 API at the earliest opportunity. Sending messages (including upstream messages) with those APIs was deprecated on June 20, 2023, and will be removed in June 2024.

@shaffe-fr
Copy link

shaffe-fr commented Jun 12, 2024

Hi,
It looks like new message format is not yet implemented. Is it planned?

@matiss-zalans
Copy link

@dragermrb Thanks for the solution. We are using your fork. Just wanted to leave a comment here. I know that main project does not allow to use multiple fcm api keys with config structure, but that can be dealt with by using ->setApiKey() . Here I had a bit of a headache. When initializing FcmV1 with default configs or setting projectId the url property was updated. I was using ->setConfig() to set everything at once, that property was not updated. So just a feedback. You could add a check to update url property after setting the whole config. Was trying to find ->setUrl(), but class didn't have that, but PushService::class had that so I had to contruct the full url the same way as in your class. So another feedback. You could override ->setUrl() with project-id injection or something like that where users pass can project-id and code itself could use when reading from config or calling ->setProjectId().

@dragermrb
Copy link
Author

Hi @matiss-zalans

I have overwritten setConfig() method to updates the URL

@pushpak1300
Copy link

Any plans to merge this ?

@hossamadelelsayed
Copy link

is this PR will be merged soon ?

@pultho
Copy link
Collaborator

pultho commented Aug 13, 2024

Hi thanks for your contribution here. I will have a look at this next weeks and will prepare a release for that.

@AbdulRahmanIqbal
Copy link

how much time it will take to fix?

@adrianpaiva1
Copy link

@dragermrb I think you need to update your FCMV1Channel class to include the buildData method, your code currently doesn't work when using the FCM Channel in Laravel Notifications. The google API returns errors for the request keys that are no longer valid (sound, color, etc)

this is my custom channel class that works for me

image

@dragermrb
Copy link
Author

Hi @adrianpaiva1

Class Edujugon\PushNotification\Channels\FcmV1Channel inherits from Edujugon\PushNotification\Channels\GcmChannel, and it already implements buildData()

@adrianpaiva1
Copy link

hi @dragermrb yes but because the buildData method there is including the 'sound' and 'color' fields in the request the Google API is returning an error as they aren't supported anymore I believe.

I'll post the error response from the API later today.

image

@adrianpaiva1
Copy link

image

@dragermrb
Copy link
Author

@adrianpaiva1
Copy link

@dragermrb it looks like those keys are only valid in the 'android' key of the request though, currently it's including them in the base notification object so it's giving that error

https://firebase.google.com/docs/reference/fcm/rest/v1/projects.messages?hl=en#Notification

@dragermrb
Copy link
Author

Hi @adrianpaiva1

The problem only occurs when using Laravel notifications. Since I don't use them I couldn't reproduce the problem.

I need to do some work to correctly generate the payload from an instance of Edujugon\PushNotification\Messages\PushMessage

I'll post the changes when I have a chance.

@adrianpaiva1
Copy link

Thanks @dragermrb one other thing I noticed was the status codes here. I think this should only be a 404 status code.

I was using the unregistedDeviceTokens to remove any invalid tokens for my users and including the 400 status code here means that if I send any invalid request parameters my tokens will be deactivated even if they are valid. From the docs it looks like 404 is correct to me for detecting deactivated device tokens.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants