I've been looking everywhere for an answer to this, it says it goes something like server > GCM > client, the client must register and then it sends the registration token back to the server, but the 'client' part im confused about, does this only work on applications on the device? or can the app be on a website too? so for example if my app is a website, can I have the registration process on a website instead of an actual app on the device?
Yes, the currently listed client apps are Chrome, Android and iOS. Fortunately, you can use Progressive Web Apps to handle push notifications to websites.
The usual prerequisites are listed there, such as creating the Google Developer Console project, and other PWA fundamental configurations (add, register, and install Service Workers). The succeeding steps are PWA-specific implementations for you to have push notification implemented on the web page.
Happy coding!
Related
I want to be able to remember a user's device using Amplify's hosted UI with React. I set up MFA as required in the user pool. In "devices" I set Do you want to remember your user's devices? to "User-Opt In" and Do you want to use a remembered device to suppress the second factor during multi-factor authentication (MFA)? to "Yes". In the React side I'm using the withAuthenticator HOC.
The problem is when I login, I get redirected to the confirm sms code page without the application or amplifying remembering the device. Also if I look at the device in the user pool, it has the status: note_remembered.
Is there any way to configure this through the hosted Amplify UI and if not how would I do it programatically?
I looked through all the docs and don't see anything even though this seems like a pretty ubiquitous use case.
It has been a while since I developed an Authentication Engine using Amplify. After going through the official Amplify Auth documentation and several Github threads, I was unable to find any API or technique to implement Cognito's Device remember feature.
In this case, I would recommend using a hybrid approach and using the GetDevice, ConfirmDevice, and UpdateDeviceStatus API calls in the native AWS JavaScript SDK, as the functionality is completely supported there.
Apropos which, Amplify is lacking a lot of imperative Cognito features, and I would implore you to raise a support request with the concerned AWS team.
Today I received an email with the above as subject and this in the body :
Dear Android developer,
To keep your access to Google APIs, review the OAuth client used by your Android application by September 30, 2019.
Google requires developers to register all Android apps that request Google Account data and interact with Google APIs. The following Android package name you maintain may require the registration of an OAuth client:
com.myappname (not my real app name)
To register an OAuth client, make sure to either:
Have an existing project on Google Cloud Platform for the app you publish.
Create a new project and configure it correctly.
For the app, make sure there’s an Android OAuth client for the package name and SHA-1 signing-certificate fingerprint. If your app uses certain sensitive or restricted scopes, you’ll also need to submit your app for verification.
Apps without a properly registered OAuth client may not get Google Account or API data after September 30, 2019.
Thanks,
Google API team
I have a GCP project that has 2 OAuth 2.0 client IDs with the package name for this Android app (one Debug, one Release) and SHA1 fingerprint. Google login has been working for years with no issue. App is also verified (though we don't use any sensitive scopes). Anybody received a similar email or know what possibly might be missing?
This is neither a misfire or a threat. It's more of a reminder than anything else. All people who interact with Google User data get this email, and the point of this is to simply tell people "Hey, if you need to, register an OAuth client, do it by September 30th.". This is explicitly clear on the wording of the email. You can see here:
The following Android package name you maintain may require the registration of an OAuth client
The keyword being "may". Since, from what you've posted, you already registered your client, you should be good to go. Everything beyond this:
com.myappname (not my real app name)
Is nothing more than instructions on how to register your client. Everything above it is warning, that if you haven't, register your client. It's saying that it's possible that you haven't registered your client, so make sure you have.
Long story short, if you registered your client, you're good to go.
I am building the backend for our company's mobile app and we need to send notifications to users from API based on some events. I need some advice on how I can implement this. I am looking for a platform where I can send notifications for both IOS and Android. I recently came across Firebase and got some info that the mobile-app will send a device token to the server, then we will handle the push notification using this token. My assumption here is, I need to save this device token for all the users in a database and send the notification as necessary. Is this the best approach or are there any other good approaches for this? I am pretty sure there will a lot of solutions where I do not have to handle this myself (in database)
I was also looking into Azure Notification Hub for this, but the cons I felt here is that my UI guy (outsourced) is developing the application in React Native and I have not seen any good examples of React Native using Azure Notification Hub.
I am expecting around 1000 users for my application and I am developing my backend in ASP.NET WebAPI. Mostly I will have 2 types of notification
Push notification to specific user.
Push Notification regarding new installations to all the users
Well, according to my experience the best way and the easiest way is using firebase. You will have a lots of option there. In fact according to their comment, whether you're a beginner, intermediate or advanced React Native developer you can be up and running with React Native Firebase in no time.
https://www.npmjs.com/package/react-native-firebase
For more information and adding a project:
https://rnfirebase.io
Firebase getting start:
https://github.com/invertase/react-native-firebase-starter
How does it work?
Firebase Cloud Messaging architecture diagram
An FCM implementation includes two main components for sending and receiving:
A trusted environment such as Cloud Functions for Firebase or an app server on which to build, target, and send messages.
An iOS, Android, or web (JavaScript) client app that receives messages.
You can send messages via the Admin SDK or the HTTP and XMPP APIs. For testing or for sending marketing or engagement messages with powerful built-in targeting and analytics, you can also use the Notifications composer.
last comment copy-right: https://firebase.google.com/docs/cloud-messaging/
I'm adding a login page for my mobile app, so that it integrates with Bluemix Single Sign On. I'm at the step to configure the Node.js app following the Bluemix Doc at Configuring a Node.js app. The example here about callback is for a web app. In the mobile app context, I don't have a redirect URL. So this code for example:
app.get('/auth/sso/callback',function(req,res,next) {...}
On the mobile client side, do I do a GET to /login?
I already have a login implemented using Mobile Client Access service. Is it something I can build up upon? For example,
app.post('/apps/:tenantId/:realmName/handleChallengeAnswer', function(req, res {...}
Can I call the Single Sign On API in here?
Thanks a lot for your help!
Jen
Is your mobile application based on nodejs? If so and you use a webview on your mobile application you could leave to the webview component to manage your authentication flow like working with a browser.
You instead have to manage authentication if your application is integrating with Rest APIs, in this case you could use SSO but your application has to manage cookies like a browser.
Bluemix Single Sign On so far has only been tested on web applications. I have no knowledge on whether Single Sign On would work smoothly on mobile applications.
Also, the Bluemix Single Sign On follows the OIDC protocol. So the redirect URL is a mandatory parameter when using the service, unfortunately.
Regarding building upon your login implementation, to my knowledge, it is not possible to include your implemented login in place of what is provided with the Single Sign On service. But you can choose to add the login implementation in addition to the login needed when using Single Sign On.
Hope that addresses your questions.
i'm building a website that uses WebRTC to share audio and video. Now i'd like to access WebRTC features on Android devices so i can create an app that can receives audio and video streams from the website.
I've looked for a technology allowing me to do that and I've found SkylinkJS.
It looks great but i'm wondering something. Can i build a custom authentication system on top of SkylinkJS logic. What i mean is that i'd like to make sure the connection to SkylinkJS rooms are initiated by users actually authenticated on my platform.
At the moment, i do that using socket.io but i can do it since i'm using raw WebRTC. How can i do that using SkylinkJS? Using the REST API?
Thanks.
PS: i cannot tag this question with 'skylinkjs' since it's a new tag, but it mights be cool if someone could do it.
Yes you can integrate that with the REST API in this Applications REST API link here - . You can generate your own credentials.
You can generate the connecting credentials from your server and then when the User logs in, generate the credentials for Users to connect to the Room. See more in their support article.
SkylinkJS uses key based authentication mechanism to authenticate against the Temasys signaling servers. This ensures that any application using Skylink can only connect to calls in your application if the app can provide the same secure keys (from your Temasys developer account).
Your best bet in looping in Android would be to use the android counterpart. http://skylink.io/android/