Currently I can use messenger bot on my pages only, but is it possible to create such a bot which can be installed on other's pages?
At this moment I only see my pages on app subscription page.
Yes, you can use your application on many pages.
You need to subscribe your app to another Page via POST me/subscribed_apps. (with Page access token)
After subscribing, your application will receive messages sent to other Page and you'll be able to send back message.
Check out fb documentation about Webhook subscription.
Related
I have just today realised that the authorisation emails sent from my perfectly legitimate Firebase backend are being flagged as malicious by Microsoft Outlook's "Advanced Threat Protection"
There is no reason for this other than perhaps it was flagged during development due to me sending myself repeated confirmation emails in order to test the functionality.
This warning does not show up in regular hotmail/outlook accounts, but I am an Office 365 subscriber so it appears as though I am lucky enough to get this "advanced" protection which protects me from my own completely non-malicious website.
Should I contact Microsoft or Firebase for a solution?
Thanks a lot!
Update: I contacted Firebase support and received the following:
My name is XXXX from Firebase Support, thank you for reaching out to us, problems on Microsoft services such as this “Advanced Threat Protection” is not in my area or expertise, I would suggest to open a ticket with Microsoft for this issue, I see that there is already a topic on Stack Overflow, please be sure to check other Firebase community channels as well.
I understand that this isn't Google's problem to solve, but it would seem any Firebase app using email verification is going to run into trouble with Microsoft email systems. Which is a lot of corporate and government systems...
Any suggestions on how to get some attention paid to this from either Google or Microsoft?
Cause
This error is caused by having inconsistent domains in the email. By default, user management emails link to the default action handler, which is a web page hosted at a URL in your project's Firebase Hosting domain ([project].firebaseapp.com), rather than the the same domain you may be sending emails from (veritification#yourdomain.com).
Solution
Make this “action link” go directly to your website. This will solve the outlook warning, and also make it less likely you'll end up in spam filters in general. On your website, you have 2 options for how to handle the actual validation.
Both solutions below require your domain to be authorized.
This can be done under Authentication -> Sign-In Providers -> Authorized Domains
Option 1 - Use Custom Email Action Handlers (Hard option)
You can setup a custom email action handler so that these actions take place directly on your website, rather than on the firebase hosted page. This is a more integrated experience.
This can handle
Resetting passwords
Revoking email address changes—when users change
their accounts' primary email addresses, Firebase sends an email to
their old addresses that allow them to undo the change
Verifying email addresses
1. Create your custom email handler page
custom email action handler page - firebase docs
2. Update Email Template In Firebase
This can be done under Authentication -> Templates -> Email Address Verification -> Customize Action URL
Option 2 - Just Redirect (Easy option)
Link the email back to a page on your website, that will immediately perform a javascript redirect to the [project].firebaseapp.com authentication page, carrying through the URL parameters required to perform necessary verifications and changes.
For Example
action url for email template: https://www.yourdomain.com/account-action (firebase will attach the appropriate params to the url automatically)
Javascript redirect on your website goes to ”https://project-name.firebaseapp.com/__/auth/action?” + params
I recommend ensuring you implement the continueUrl in your verification email delivery so that the user can easily get back to your website.
If you're using Firebase hosting, and you're serving from their built-in your-project.web.app address, then you can simply use the other built-in, your-project.firebaseapp.com, as your site address instead -- no configuration needed.
The .web.app address is a bit sexier, but the various action emails are actually sent from the .firebaseapp.com, and Outlook is suspicious of the mismatch. Having users originate from the .firebaseapp.com address solves the issue.
I opened a GitHub issue about this: https://github.com/firebase/firebase-js-sdk/issues/5021][1]
I have a Chrome extension that communicates with my Meteor app through a REST API created with the Restivus package.
The user authenticates to the REST API and then uses authenticated tokens to make any further requests.
So far, everything works fine, as long as he stays within the extension. However, from the chrome extension, I'd like to redirect the user to his profile page on my main website. When that happens, he's no longer authenticated, and must re-sign-in to access the profile page.
I figure this is because the REST API session and the webpage session are two completely different sessions on the server (even though both the API and the webpage run from the same server). My question is, is there a way to maintain the user's logged-in state as he moves from the extension to the main website?
I figure there are a few options:
I'm using the standard meteor accounts package. Is there a way to push whatever standard cookie / data that the accounts package uses, to the user's browser, so that when he goes to the website, he'll be considered logged in?
Push a custom cookie to the user, which I then check for and log him in when he first comes to the website. However, I don't know how to push a cookie through a REST API or generate one in the Chrome extension
Use DDP to communicate with the second session and transfer the login credentials.
I don't know if these are the best options (or even how to implement them if they are...). Has anyone figured out a way to do this already? Thanks!
I would suggest you to develop your own flow of authentification using a token as an URL parameter. You should achieve a similar experience that slack provides with magic authentification links
The idea is to generate a token and add it to the Meteor.users collection for the user logged in your chrome extension.
Then, redirect your user to an url with the token as a parameter. The app checks which user is linked with this token and log him in.
You can get inspiration on what is done in the account package to handle enrollment and reset links, or in the passwordless package
I'm working on windows Azure ASP.NET integrating Paypal in it.
I succeeded creating the listener page in my website. After "VERIFIED" was received the page updates the database as I requested, but I cant send a mail - I don't get an error message, but the mail isn't in the inbox (I'm using sendGrid).
I can send a mail in other pages of my website.
What is the best way to send a mail from the listener page in asp.net?
Thanks
If the script is running but your email isn't getting sent then there must be some sort of an error happening, or may be a simple logic flaw in your code.
I wrote this article a while back on how to test PayPal IPN. I'd recommend taking a look at it and following the steps. It will help you track down the problem and get it resolved.
I' working on a login page where I want to use WeChat as login option and I have a WeChat official account. In my understanding of the documentation it's supposed that the next link would generate a QR code to scan and after the user authorization redirects somewhere else...:
https://open.weixin.qq.com/connect/qrconnect?appid=wx8bxxx21bxxxx0fxxx&redirect_uri=https://myhostname/oauth2.php&response_type=code&scope=snsapi_login&state=101#wechat_redirect
But the link doesn't work. I don't know if I'm missing something or maybe the site https://myhostname/oauth2.php has to have a previous authorization call to WeChat... ???
Somebody has worked with this WeChat stuff?
Thanks in advance!
I realized later that you must have a WeChat Open Platform Account, where you register your web application, wait for approval, and then give it the login permission to get access to that QR Code functionality
If you are working on how to login web page after scanning qrcode of an offical account on the web page.
There are two ways to approach this.
Scan service official account
You can generate the qrcode injected with parameters. then after you scan, there will be an event triggered in your backend.
Capture the event and extract the parameter, then do the authentication in the way you want.
The basic workflow:
app frontend request your backend for a session.
app backend call wechat api to generate a qrcode, injecte with any parameter you like.
app frontend show the qrcode.
user scan the qrcode of the service account.
if user did not subscribe, then subscribe the official account.
backend receive the scan event, extract the info and authenticate the user.
Scan subscription official account
In subscription get less programing support, but you can still achieve it by design a random code.
The basic workflow:
app frontend request your backend for a session.
app backend generate a random code.
app frontend show the qrcode of the official account with a random code.
user scan the qrcode of the subscription official account.
if user did not subscribe, then subscribe the official account.
user input the random code in the official account message UI.
backend receive the code and authenticate the user.
attach user info in your db with openid if you want.
Use an open platform to do it in the smart way.
If you doing this for one official account, it is ok. Let's say if you want to reuse this for multiple official accounts.
Maybe can use the open platform way, so you can have only 1 backend to handle multiple accounts.
Wechat offer an open platform, here is the get start doc.
Register an open platform need to pay 300RMB for verification, more troublesome part is, you need to register a company to be qualified to pay.
So maybe using a third party open platform will be a better choice. Such as Dagui Qrcode Tool.
Key take aways
Use parameter Qrcode for service official account login
Use account qrcode with random code for subscription official account login
Use open platform for scaling
Authentication is flexible, the key is the event exchange flow.
More secret technology related to wechat development, can refer this article
You need to set the OAuth2.0 web authorization domain to your subdomain in your redirect url, such as: wechat.myredirectdomain.com.
This setting is hidden on the WeChat official account dev setting dashboard, some where in between the API list, make sure you set it properly.
I am currently using the Facebook Javascript SDK and the Facebook C# SDK (soley for retrieving user graph objects).
Everything so far is going great except for the following scenario:
User logs into Facebook
User opens a new browser window and visits my
site
Using the Javascript SDK, I can use the FB.getLoginStatus method to determine if they are connected or not (which they are in this scenario as I have previously authorized my site/app for the facebook login).
However, I need to be able to detect upon the homepage of my site loading for the first time, ideally server-side, if we are in this 'connected' state, and if so, render some different content to screen (logged in vs not logged in).
I can't currently see a server-side method in the Facebook C# SDK that enables me to do the equivalent of FB.getLoginStatus (clientside).
I should point out that any subsequent changes to the users loginstatus is handled via subscribing to the auth.authResponseChange event and all is working fine there, but its the first time page load when the user first hits the site that's the problem.
There isn't a way to do this on the server with any Facebook SDK. You must detect the user's status with the Facebook Javascript SDK. The reason for this is because this information is stored in cookies that are either only readable by facebook.com or that are on you domain, but were set by Facebook and should not be parsed by your app.
You can parse the cookies on your domain if you like, but it isn't recommended because Facebook considers those cookies to be an internal implementation detail and does not guarantee their contents. They could change at any time and break your app.