Is it possible to disable Google Experiments for debugging adding manually a variable to the Url address in the browser?
Like for example: debug=1
http://www.example.net/?var=kekiql&fo=fiusispn&debug=1
Related
I'm using a Google API (e.g., for Maps Embed) with a key that is restricted via a list of HTTP Referrers. In this case, the map is embedded in my.site.com, so within the Google API -> Credentials page, I allow access for referrer .site.com/. When I visit my.site.com from most browsers, Google maps displays correctly as the browser sets the referrer field to my.site.com. When using the Brave browser, however, it sets the referrer field to the origin and displays an error:
Request received from IP address 98.229.177.122, with referrer: https://www.google.com/
Of course I could add google.com to the list of allowed referrers, but that defeats the purpose of limiting the use of the API key to my own website - anyone could "borrow" the API key, add it to their site for the same API, and anyone using Brave would be able to access the feature. Now that each access costs $, I'd rather not do this. Any ideas for a work-around?
Note: #geocodezip - thanks for the reference. Indeed, I forgot to add that when I set the site-specific shield to "All cookies allowed", or even completely turn shields off for the site, the behavior is still the same (error). However, in the default shield settings, when I set the cookies field to "All cookies allowed", then it works as intended (maps are displayed), even though for the default settings section it states:
These are the default Shields settings. They apply to all websites
unless you change something in the Shields panel on a particular site.
Changing these won't affect your existing per-site settings.
which I interpret to mean that the site-specific settings take precedence over the defaults.
So I'm thinking this (site-specific cookies setting not over-riding the default) is a brave bug, though that is a bit separate from my initial hope for a different approach that didn't require manual intervention on the user's part.
I'm having an unending issue trying to use the AppEngine API explorer with the stupidly simple helloworld example.
When trying to navigate to the url to explore the API my Chrome browser redirects to HTTPS from the default HTTP and no API's are listed. I have gone through every possible fix I can find (Like this, and all of these) and none are working reliably.
What's the most infuriating is I have gotten the API listed TWICE but now no longer displays with any of the methods below.
The setup I had when it worked the first time:
Chrome launched with "C:\Program Files (x86)\Google\Chrome\Application\Chrome.exe" --unsafely-treat-insecure-origin-as-secure=http://localhost:8080 (As per the tutorial)
The url being: (http://)apis-explorer.appspot.com/apis-explorer/?base=http://localhost:8080/_ah/api&root=http://localhost:8080/_ah/api#p/
The second time it worked was using also using the above URL but lasted only a second before being redirected to HTTPS and not listing anything.
Some specifics:
Windows 10 OS.
Every time the page loads I get the "The API you are exploring is hosted over HTTP, which can cause problems. Learn how to use Explorer with a local HTTP API." message, even the times the API displayed correctly.
Every time I now load any of the API Explorer URLs I get redirected to HTTPS, and nothing is listed. Also the URL is escaped (%3A instead of ':'). Not sure if it's important but the first time it worked the URL was HTTP and NOT escaped.
I have tried the shield in the search bar and enabling Load unsafe scripts ( from here).
Tried launching Chrome as usual and with the flags --unsafely-treat-insecure-origin-as-secure=http://localhost:8080 and/or --allow-running-insecure-content (from this answer).
Tried http://localhost:8080/_ah/api/explorer
Tried http://apis-explorer.appspot.com/apis-explorer/?base=http://localhost:8080/_ah/api#p/
http://localhost:8080/_ah/admin works correctly and shows the Admin console every time.
Since the API's being listed once I haven't touched the project code, but restarted the server, Chrome, and tried different URLs on more occasions than I care to count.
I also tried accessing the API URL directly as explained in this answer but cannot find the correct URL to access the helloworld /sayHi endpoint. Maybe someone can help me work out what I need to prefix it with as all of the variations I try give me a 404.
Any help would be a very very appreciated.
We have a CMS that powers over 2000 school websites. The admin sites for each of those websites are all under the same root domain, e.g. *.myadmin.com. We are working on integrating OneDrive File Picker on multiple pages in all of those admin sites.
We have an issue with the Redirect URLs in the API Settings. We tried to set the Root domain field to myadmin.com by setting Redirect URLs: to https://myadmin.com. In JavaScript, we initialize the File Picker like this:
WL.init({
client_id: window.OneDrive.clientId,
redirect_uri: ''
});
WL.fileDialog({
mode: "open",
select: "single"
});
That results in a popup window saying:
We're unable to complete your request. Microsoft account is experiencing technical problems. Please try again later.
In the address bar of the popup window, there's a further error description(url decoded):
error_description=The provided value for the input parameter 'redirect_uri' is not valid. The expected value is 'https://login.live.com/oauth20_desktop.srf' or a URL which matches the redirect URI registered for this client application.
Putting a specific url, like https://subdomain.myadmin.com/homepage, in the API Setting would make the Picker work on that specific page, but not on other pages. Looks like it's looking for an exact match. Obviously it's not practical for us to create a separate app for each page that uses OneDrive.
The problem can be solved by disabling Enhanced redirection security on the API Settings page. That option existed a few weeks ago when we created an app for development, but was marked as deprecated. Today when we created a new app for production, it wasn't there anymore, which I think is now enabled for all new apps.
We had a similar issue with Dropbox Drop-ins Chooser, but we were able to solve the problem by setting myadmin.com as the domain of the app.
Is there any work around for this problem?
Thanks for your help and suggestions.
The only way I could get this to work was
Make sure the exact single web page on a single domain is configured and working for one drive (the url running OneDrive needs to be correctly configured in Microsoft account Developer Center
Then use this page inside an iframe (even if it is a completely different domain)
then use postMessage to pass the data back to the parent iframe to utilise
a working copy (link may be removed at any time )
Testing OneDrive in an iframe
Other pertinent urls
browser support for postMessage
Browser support for postMessage on stackoverflow
postMessage documentation
Some example usage of postMessage
example usage of postMessage
another example of use of postMessage
You can add multiple Redirect URLs as long as all of them are in the same subdomain. Each redirection URL needs to be specified explicitly:
The bug with the Microsoft developer console mention is resolved if you put the root domain you want first, then the 2 sub domains.
Add 3 entires:
1. domain.com
2. sub1.domain.com
3. sub2.domain.com
I want to use an application that checks for broken links. I got to know that, Xenu is one such software. I do not have access to internal aspx/http files on a drive. The Problem I am facing is the Website requires the user to be authenticated. After login I need to crawl the site to determine which links are broken.
As an example, I kick off with mail.google.com. We end up typing the Username and password after which we are served different URLs. If I give the Xenu (or similar programs) the link such as mail.google.com it will not be able to fecth URLs inside the mail.google.com which will be of type - /mail/u/0/?shva=1#inbox/ etc. There lies the problem.
With minimal or least scripting language how can I provide Xenu (or other similar app) capability to Login by providing external URL (mail.google.com) in this example in order to do whatever xenu has to do.
Thanks
Balaji S
Xenu can be used with an authenticated user as long as the cookies are persistent. You will need to enable cookies in Xenu and login once yourself using IE.
From their FAQ:
By default, cookies are disabled, and Xenu rejects all cookies. If you
need cookies because
you have used Internet Explorer to authenticate yourself before
starting a run
to prevent the server from delivering URLs with a
session ID
then you can enable the cookies in the advanced options
dialog. (This has been available since Version 1.2g)
Warning: You
should not use this option if you have links that delete data, e.g. a
database or a shop - you are risking data loss!!!
You can enable cookies in the Options menu. Click Preferences and switch to the Advanced tab.
For single page applications (like gmail) you will also need to configure Xenu to parse Javascript
This is done by modifying the ini file (traditionally at C:\Program Files (x86)\Xenu135\Xenu.ini) and adding a line of code under [Options]
Javascript=[Jj]ava[Ss]cript: *[_a-zA-Z0-9]+ *\( *['"]((/|ftp://|https?://)[^'"]+)['"]
There are several variations provided in their FAQ, but I didn't get them to work perfectly.
I went to Twitter's resource page here (https://twitter.com/about/resources/tweetbutton) and got the following code:
Tweet<script type="text/javascript" src="//platform.twitter.com/widgets.js"></script>
When I put this in my Wordpress template, I don't get the Twitter button -- I just get the text "Tweet". However, when I change the src for widgets.js to include https:// or http:// at the beginning it works.
Could it be that it's just an error that they forgot the protocol? Also, do you think it is better to use https (for consistency with the share link) versus http, or does it not matter?
Thanks for your suggestions.
The URL "//example.com/script.js" tells the browser to open the URL using the protocol of the current page, which is likely to be "file://" if your browser opened an html file on your own machine. Of course, you don't have a file called "file://example.com/script.js" on your computer.
In the past, urls for embedded widgets used to include the protocol (http or https), but a site visitor would receive warnings whenever a secure page loaded a script from an insecure page, and sometimes even vice versa. Now, widgets from Twitter, Google Analytics, and other sites no longer specify the protocol so that the same embed code can work on any page on the internet. The downside is that this does not work when you embed such a widget into a file and view it on your own browser by double-clicking it!