I am the owner of a chrome app which is currently a hosted app on https://mydomain.com. I would like to add push messaging to it, so it will have to become a packaged app.
However, I don't want to lose the ability to prompt users on the website to install the app if they don't already have it installed.
There are many ways I've come up with to test this, but none of them seem satisfactory:
chrome.app.isInstalled, the method I currently use is unavailable for packaged apps.
Inserting a DOM element is a recommended practice, but only available for extensions; content_scripts is disallowed for packaged apps.
Setting a cookie could work, but the cookies permission is disallowed for packaged apps.
Setting a cookie using a webview might be possible, but webviews are sandboxed, and do not share cookies with chrome.
Detecting a file in the app might work, but the web_accessible_resources permission is disallowed disallowed for packaged apps.
Specifying url handlers seems like it might work, but It looks like they only work for urls in the address bar (i.e. they don't seem to handle requests).
Setting externally_connectable works, but it requires a permissions dialog saying that the app would like to "communicate with cooperating websites". The permission is this vague even if I specify https://mydomain.com. I would like to avoid this since people tend not to update apps when permissions change.
Does anyone know of a way to determine whether my packaged app is installed if I own both the app and https://mydomain.com?
url_handlers or externally_connectable is the way to go. You've understandably ruled out the last option because of the extra permission warning (which would disable the app until the user approves the new permission).
url_handlers does offer a solution without requiring extra permissions:
At your server's side, if the user doesn't have any cookies, redirect to some other URL at your server. E.g. http://example.com/landing/ -> http://example.com/landing/?noapp.
If the app is not installed, the redirect will be followed. On that landing page, use history.replaceState(null, null, '/landing/'); to change the URL back to the original URL.
If the app is installed, the chrome.app.runtime.onLaunched will be triggered, and the redirect is not followed. On your website, use setTimeout to check whether or not the page is unloaded.
If the previous method doesn't suit you for some reason, then there is one more (fragile) alternative: Set up an API endpoint at your server and use CORS. Because your app does not have the permission to access this resource, the AJAX request automatically gets an unforgeable request header (Origin: chrome-extension://.../...). You can detect the presence of this header, and mark the app as installed for the specific IP address. If you choose a right frequency, you will have an up-to-date ip-to-app mapping.
This doesn't work for multiple computers behind a NAT though. And I (as a user) would be concerned about my privacy if you kept pinging home...
Related
The “WP Mail SMTP” revoked the connection from my G-mail account again and again.
No password changed.I missed my order notification again and again.Please tell me why it is happening.
WordPress Version:- 5.6
PHP Version:-
WP Mail SMTP Version:- 2.6.0
Web Server:- Apache
PHP version:- 7.3.5
License key type:- lite
To solve it I accessed WP Mail SMTP settings on WP Admin Dashboard and, in the Authorization, pressed "Removed the Connection"
And then allowed the connection again ("Allow plugin to send emails using your Google account")
And that redirected to the following screen (after login), and had to allow
Note: One needs to be in the Google Account that one configured the API (see here how to configure WP Mail SMTP for Google Workspace/Gmail Mailer)
Token has been expired or revoked, but it is hard to know exactly what is the problem.
My guess is that it could be happening for a variety of reasons, such as resetting the password of the account one is using.
A WPMail SMTP creator wrote (here) the following:
Hi everyone,
it looks like this is happening to more and more users, but we don’t
know what the reason behind this account disconnect is. We have a lot
of testing sites set up, and we never experienced this issue. I just
rechecked my testing sites.
One of the main things that could cause this issue is if your
Google/Gmail API app is in “Testing” mode. Could you please check if
the google API project is in the “Production” mode by going to the
Google API console, opening the project for our plugin integration,
then go to “OAuth Consent Screen” and check the “Publishing status”.
More info can be found in this screenshot. It should say “In
production”.
If that’s not the reason, then we have to go over all the Gmail API
project options together and see what the differences are. I think it
has to be something on Google’s side since they are the ones that
invalidate the token, not us.
And to answer bst7’s questions: The Google API app is created by you,
to be used just by you, even though on the free Gmail accounts you
have the app set to “External use” (no other option is available), but
nobody else will use this app apart from you, since you are the only
one that knows the project credentials and have logged into it from
your secured WP admin dashboard.
Our plugin requires top-level permission because that’s the best way
to future-proof our plugin development. If we were to improve our
plugin and would have required only the minimal permission level, upon
the plugin update, your connection would be invalidated and the newly
added plugin functionality would not work. For example, we added the
support for aliases a few versions ago and if we didn’t have the
top-level permission, after the update all users would have to reset
the connection manually in order for the Gmail mailer to work properly
again. It’s just a way to make sure we can keep improving our plugin
without any issues for our users.
However, in my case the Publishing status is "In production" and the problem also happened.
I'm trying to build a login page for my Shiny application, using the auth0 services, nginx, node.js and the git repo github.com:auth0/shiny-auth0.git.
You can find the full tutorial here
Everything works fine, except for the fact that I can't login using a valid username/password combination (made within the auth0 webpage). It is possible though to login using for example your Google account (it's redirected to Shiny application, as expected).
The generic error message I get is stating WE COULD NOT REACH THE SERVER. PLEASE CHECK YOUR CONNECTION AND TRY AGAIN.
I can't find any working solutions in the documentation, or on the forum of Auth0. Did anyone experience similar problems, using Auth0, possibly in combination with Ubuntu 16.04, Node.js, R Shiny and Nginx and found a solution?
Help is highly appreciated!
The trick lies in the Allowed Callback URLs and the Allowed Origins (CORS). Both fields need to be filled in properly within the Auth0 Client setup. This means that the allowed callback URL needs to be equal to your domain of the Shiny app, starting with the proper protocol (in this case http) and ending with /callback. The same URL should be used in the .env file. In my case, this was something like http://ec2-123-456-789.eu-central-1.compute.amazonaws.com/callback.
Then don't forget to also use the Allowed Origins (CORS), since the origin is not exactly equal to the callback. The origin uses https protocol, instead of http. Hence use something like https://ec2-123-456-789.eu-central-1.compute.amazonaws.com for your Origin.
I'm having a similar problem as was discussed in this question:
authClient.login returning error with "Unauthorized request origin"
I can't find anything on the firebase site that directly addresses this problem so I have 2 questions about the "unauthorized request origin":
1.) If I'm testing my program through my own computer (as in, it's just a file on my computer), what exactly am I supposed to add to the Auth panel? I tried following the advice offered in the link above but no luck.
2.) My eventual plan is to create an app using firebase and it's login system. Is this going to be a problem for when users try to login? Is there going to be something that I need to allow so that any user will be allowed to login to the system?
With the release of Firebase Simple Login, which contains a number of OAuth-based authentication methods (Facebook, Twitter, GitHub, etc.), we included the idea of 'Authorized Origins'. Without this restriction, malicious sites could pretend to be your application and attempt to access your users' Facebook, Twitter, etc. data on your behalf.
By restricting the domains for these requests to ones that you control and have verified, we can protect your users' data. Once you have configured your application domains, your users will be able to log in seamlessly and securely from the domains you defined.
To fix this error, log into Firebase Forge (by entering your Firebase URL into your browser), and navigate to the 'Auth' panel on the left.
For testing locally, you'll need to run at least a barebones webserver on your machine, rather than loading your test files via file://. The easiest way to run a barebones server on your local machine is to cd to the directory of your files and run python -m SimpleHTTPServer, which will allow you to access your content via http://127.0.0.1:8000/....
For your users, configure the domains that you'll be using to host your application. This can be any number of specific subdomains (such as a.b.www.domain.com) or high-level domains which will act as a wildcard (domain.com will allow requests from *.domain.com).
You can configure multiple application domains or IPs here, comma-delimited.
See https://www.firebase.com/docs/security/simple-login-overview.html for additional documentation about application configuration for Simple Login.
I hope that helps! Feel free to ping me directly if you have further questions.
Is there a way to get the logged in user from a vb.net web application? IE, if someone logged in as "foo"/"bar" on their local machine accesses the site, I need code to get me "foo"/"bar". This is for a passthrough on our intranet, where everyone uses the same Active Directory.
Essentially, I need to harvest the username of the logged in user and check it against our ActiveDirectory instance. If that fails, I need to check for Request variables and check those (that part is fairly easy). Then if THAT fails, I need to show a login screen (I also have a handle on this).
I've already come across and discarded a couple solutions for the part I'm having trouble with:
request.serverVariables("LOGON_USER") - This only works if you have anonymous access turned off in IIS, and that must be on to use forms authentication (which I'm using).
http://www.thescarms.com/dotnet/IsInRole.aspx - This solution does not seem to work for some reason. I suspect the line AppDomain.CurrentDomain.SetPrincipalPolicy( Principal.PrincipalPolicy.WindowsPrincipal) is the issue, but the meaning of this line is buried so far I can't figure out what it's actually trying to do.
HttpRequest.LogonUserIdentity?
if you're using Forms Authentication, have you tried System.Web.HttpContext.Current.User.Identity.Name?
The web browser will not send the user's local credentials to the web server unless two things are true:
The web server asks for them (i.e. Anonymous Access is disabled, and Windows Integrated Authentication is enabled).
The web browser has been configured to send local credentials if asked (an Internet Explorer option, available in FireFox via plugin, not sure about other browsers). If the browser has not been configured to send the information and the web server asks, the user will be prompted within a pop-up login screen.
I have a Drupal site with user logins. Embedded within this site is a Flash application that shows some data to everybody but allows extra functionality if the user is logged on. From within Flash, I'm using XMLRPC to access the system.check method (to determine whether the user is logged in) and the user.login method (to log in a user from within Flash).
Within Flash, everything works fine. However the Flash login state does not seem to correspond to the rest of the site. For example, if I invoke user.login via XMLRPC, subsequent calls to system.check show that I am logged in, but the Drupal user page still says I'm logged out. Or if I am logged in both places and then I log out via the Drupal user page, the next call to system.check still indicates that I am logged in.
How can I make the login state consistent between the Drupal GUI and my embedded Flash app?
(Note: I am not using any XMLRPC library, I am just constructing the requisite XML manually and sending POST methods using a URLRequest object.)
EDIT: I have confirmed via this question and also via testing with a Web Proxy that the SESS cookie returned by the user login page is being picked up and sent back by the flash application.
EDIT: And now I have shown experimentally that even though Flash (via Safari) is sending the same cookie, it gets back a DIFFERENT cookie when it connects to the XMLRPC service than when it requests and HTML page. In other words, Drupal just doesn't support this kind of synchronization and I'm stuck. I'm accepting the answer below that put me on the right track.
EDIT: AMHPHP is not fully released for Drupal6 as of this writing, but it turned out to be installed on the site anyway. Using the DrupalSite library, I was very easily able to log into and out of the site from flash, and the login remained consistent between flash and HTML.
I'm not terribly familar with Flash, but do the URLRequest objects "inherit" state from the browser session, including the user login cookies? If not, you'll need to explicitly send the login cookie with your hand-built request or Drupal will think that it's just coming from another web browser at the same IP address.
If you're not quite sure, using the Firebug plugin might be useful. It lets you inspect any requests that are being piped through the browser, examine their headers, and look at the raw HTTP response object that comes back.
Update: Even more important than the flash widget getting a session cookie is the flash widget getting the SAME session cookie as the web browser itself. Drupal allows users to log in from multiple machines simultaneously, so if the browser is creating one session and the flash widget is creating another, you'd see the behavior you're describing...
It can't be done.
(For details, please see my final edit to the original question and the equivalent information in my comment to #Eaton.)