Chrome Custom Tabs hide address bar - chrome-custom-tabs

I am developing a widget that customers can integrate into their apps. Their users must authenticate themselves (via OAuth). Therefore, it's preferable that my customers use Chrome Custom Tabs so that the user is likely logged in with the OAuth provider (eg. Facebook).
Is there some way to hide the address bar for a Chrome Custom Tab? The URL isn't really relevant to the end user.

No, there is no way to hide the address bar. It is critically important for the user to be able to tell which authority they are talking to when they are visiting a website, in particular when they are authenticating. This saves a lot of users from phishing.

Related

Verification required for word press site

I have no experience with this and I'm in need of major help. I have a word press website that I am trying to connect a gmail account to. So that the contact form gets sent to a gmail address. I got it all set up and it is telling me I need verification. This is only being used for my word press website. Probably very few users, not a business. Can I get around the verification process or not?
You would need an OAuth Consent Screen for your Project.
You can refer to this blog post on how you can connect a Gmail account on your Wordpress site

Firebase dynamic link flagged as suspicious in gmail

Some Background
We have an app which requires users registration
When a user registers, we send a confirmation email
The email contains a Firebase Dynamic Link to a web page and is caught by the app if it's installed
Since the final link contains a unique confirmation token, we generate a dynamic link each time using the Firebase dynamic link REST API
The generated dynamic link is something like this: https://{domain}.app.goo.gl/{randomChars}
The final link points to our domain, which is using HTTPS
The Problem
When I try to open that link in Gmail (both desktop and android), a pop-up appears that says:
Suspicious link
This link has been flagged as suspicious. Are you sure you want to proceed to {domain}.app.goo.gl?
Notes
It's weird that the top-level domain is from Google, and it's flagged as suspicious
The email contains other links, e.g. to the home page, youtube, instagram and facebook, and those open without any issue (all of them are HTTPS)
We're using Rackspace/Mailgun to send emails
Any insights will be really useful.
Edit:
I checked both domains ({domain}.app.goo.gl and ours) in MX Toolbox and no blacklist was found.
Dynamic links now use page.link instead of app.goo.gl. The latter url has been deprecated.
See https://firebase.google.com/docs/dynamic-links/create-manually

How to serve OpenGraph for a private page

we'd like to implement OpenGraph on an intranet application, so that when people share a URL from the application into a social network (Yammer, Jive, Chatter ...), it would show a nice thumbnail, description, and so forth.
The problem: because Yammer is not connected to the intranet, it follows the redirections and serves OpenGraph data from the login page...
Is there a way to behave properly in such a case ?
We've come up with 3 possible solutions:
Implement an unknown but possibly existing part of the OpenGraph protocol, to serve private pages, ignoring as well as possible the redirections
Doing some kind of cloaking - detecting the agent is Yammer or Chatter, and serve a dedicated page
Keeping the OpenGraph meta data in some kind of session, and serves them from the login page (where the social network eventually ends up...)
Thanks for your input if you've been confronted to this problem too !
Third solution sounds like the best one. Since it is allowed (by your rules) to show part of a data outside your intranet, you have to add individual thumbnail and description in the meta tags of login page.
If a user is logged in, he can see all the data from page yoursite.com/username/post123/ (as usual),
But if user is not logged in (like any bot), he will see login form (with thumbnail and description in meta tags) on the same address yoursite.com/username/post123/
So all bots will see proper OG data, all users will be able to login as usual.
(i.e. you shouldn't redirect not logged in visitors to the page yoursite.com/loginpage. You have to show a login form on all such pages)

Has anyone ever come up with a way to detect the email program a recipient is using?

I know there are ways to detect browsers based on CSS rules but I don't know if the same tricks would work for Outlook. The way I think it could work is have CSS rules that show and hide urls so that when a recipient clicks on a link I can tell which email program it came from.
I can't see how this would be possible. Browser detection is done via Javascript (not CSS). And if the user is using a non-web-based email client (such as Outlook), clicking on a link will trigger the default browser to open and load the link. The information the browser sends to your server will have no knowledge of what application caused the browser to launch.
I think your only option would be to have different links for each client and rely on the goodness of the users to click the correct link.
I also think you'd have a fairly high success rate of guessing the client based on a few factors that ARE available after the link is clicked such as:
The device type
The Browser
The Operating System
The email address (if it's gmail.com or hotmail.com you know 99% of them used the web client - or for a better match mix it with the device type)
Then you could make generalisations such as:
Accessed from Windows and not a gmail/hotmail/yahoo webmail address - probably used Outlook
Accessed from OSX and not webmail address - probably used Mail
Accessed from either and a webmail address - probably used Browser
Rules like that could probably give you some pretty meaningful statistics.
If your challenge is to see what email client the person is using, there are simpler solutions than showing and hiding links. The easiest way would be to embed an image, add a query string to it like so:
http://www.yoursite.com/image.png?email=youremail#email.com
You would then catch this serverside and get the user agent string.
The issue with this is with webmail clients like GMail and Hotmail. In these instances the user agent string would be the same as the web browser. Here you would detect the user's webmail client by inspecting the email address, eg. hotmail.com.
There are edge cases such as Google Apps for Business, but this should catch most cases.
Most email senders such as Mailchimp will do mail client analytics for you.

ASP.NET Allow Admin Users Access Basic Users Accounts

We have an ASP.Net web application currently released to the public, that uses Membership and Provider features and have our users assign to a "Basic" role. What we are working on doing is developing an administrative site, so that administrators (presumably to be assigned an "Admin" role) are able to login to the administrative site, where they will have access to a list of users in the "Basic" role.
From the admin site, we want to allow the administrators to click on any of the "Basic" users and effectively be logged into there account (loading the user's profile information in the process, as is the case when a "Basic" user logs in), while still remaining logged into the administrative account.
Can anyone please suggest a way to do the above?
Any help would be appreciated.
Thanks,
Brent
Ok, let's assume that authentication is not a problem, e.g. you either have encrypted passwords that you can munge around to effect a login or some other method of authenticating as another user whose password you do not (SHOULD NOT) have.
That is the easy part.
The hard part is that you absolutely cannot have 2 principal/identity. e.g. Request.User, which is what all of the membership, roles and profiles works off of. It is simply impossible.
A possible solution is to create a very secured bootstrap page that accepts params such as the userid only and can authenticate.
Embed an IFrame in your administrative page, send it to the right url and browse as the user in the context of the IFrame, which should not share cookies with the parent.
Mind you, this is just an off the top of my head workaround, there are sure to be issues with this approach even it could solve your problem.

Resources