I am encountering behavior inconsistent with Google's documentation on step 2 of this grant flow.
As described at https://developers.google.com/accounts/docs/OAuth2InstalledApp , when a "redirect_uri" value of "urn:ietf:wg:oauth:2.0:oob" is specified, "your application can then detect that the page has loaded, and can read the title of the HTML page to obtain the authorization code."
With every attempt I have made to use this approach, the result has been the same. After the redirect, the browser's title contains a partial authorization code, though the edit box on the page is correctly populated with the entire authorization code. (I could provide an image for illustration, but not without sufficient "reputation".) Whether I retrieve the title programmatically or just inspect it via the tab's hovertip, the code is consistently truncated at the 44th character of the title, immediately preceding the period in that position in the full code.
With only a partial code, there is no way to proceed past step 2; the documentation leaves little room for doubt that this is buggy behavior. For reference, the full authorization code works if I retrieve it by manual copy and paste (but that is not an option for me in practice).
Has anyone else encountered this behavior?
Most importantly, can Google or a representative thereof, please answer the question of "Why?" (And, assuming it's not something on my end, "When will it be fixed?")
I noticed the shorter code too. The shorter authorization code will work. You can proceed to the next step.
Related
I need to modify the body of an existing GitHub issue in a Project. All I'll be passed is the title of the issue, and a word (the word exists in the body, and I'll just need to fill the checkbox next it).
It looks like to do this I'll need to use the GET API to get the body of the issue, modify it, and then use the EDIT API to swap in the new body. However the GET API can only be called with the issue number. I need to do all this as quickly as possible. Is there some way to search via an API call?
Thoughts much appreciated!
Edit: All my issues are in the same project (and issue titles will be unique there). I've also recently discovered Github's GraphQL API, which may be applicable here.
You can use the issue search endpoint with the in and repo¹ keywords:
GET /search/issues?q=text+to+search+in:title+repo:some/repo
Of course, issue titles aren't guaranteed to be unique. You'll have to request each of the issues that comes back and see if its body contains the word you're looking for. Even in that case you could get multiple positive results.
It would be much better if you could search by issue number.
¹I've assumed that you really mean "repository" when you say "project". But if you're actually talking about GitHub Project Boards you can use the project keyword as well or instead.
I want to confirm that the words "You are not signed in" show up on a web page in Jmeter using a Response Assertion. Those words will show up only once on the web page. But, only if the user is not signed in. That phrase will also appear in the code more than once if the user is not signed in.
I want to do the same thing after the user is signed in, but only for "You are signed in" this time.
The problem is that both lines appear in the "Response Data" in JMeter no matter if the user is signed in or not. A class is used to hide the one that is not needed depending on if the user is signed in or not. So, it seems like I will get false positives if I just make the Response Assertion pattern equal to any one of the two phrases above since that text will always be in the code for that page.
I want to test if the code is actually displayed on the page.
In the XPath Assertion for each of the two messages above, I needed to add the "class" what was used for hiding one of the two messages from being displayed onto the actual web page. So, in the first XPath Assertion, here is what I put:
//*[#id='signedIn'][#class='notVisible']
Here is what I put in the second XPath Assertion:
//*[#id='signedOut'][#class='notVisible']
Now, one of the two of those will fail every time because the user cannot be both signed in and not signed in at the same time. So, this will be missing from one of the two of them:
[#class='notVisible']
Thanks for the idea of Xpath jpvee.
Hope this helps someone :-)
Is there any other use for shebangs/hashbangs besides for making AJAX contents crawlable for Google? Or is that it?
The hash when used in a URL has existed since long before Ajax was invented.
It was originally intended as a reference to a sub-section within a page. In this context, you would, for example, have a table of contents at the top of a page, each of which would be a hash link to a section of the same page. When you click on these links, the page scrolls down (or up) to the relevant marker.
When the browser receives a URL with a hash in it, only the part of the address before the hash is sent to the server as a page request. The hash part is kept by the browser to deal with itself and scroll the page to the relevant position.
This is what the hash syntax was originally intended for, so this is the direct answer to your question. But I'll carry on a bit and explain how we got from there to where we are now...
When Ajax was invented, people started wanting to find ways to have a single page on their site, but still have links that people could click on externally to get directly to the relevant content.
Developers quickly realised that the existing hash syntax could do this for them, because it is possible to read the URL's hash value from within javascript. All you have to do then is stop it from scrolling when it sees a hash (which is easy enough), and you've got a bit of the URL which is effectively ignored by the browser, but can be read and written to by javascript; perfect for use with Ajax. The fact that Google includes the hash part of a URL in its searches was just a lucky bonus to begin with, but has become quite important since the technique has become more widespread.
I note that people are calling this hash syntax a "shebang" or "hashbang", but technically that's incorrect; it's just a hash that is relevant -- the 'bang' part of the word "hashbang" refers to an exclamation mark ('bang' is a printing industry term for it). Some URLs may indeed add an exclamation mark after the hash, but only the hash is relevant to the browser; the string after it is entirely up to the site's authors; it may include an exclamation mark or not as they choose, but either way the browser won't do anything with it. Feel free to keep calling it a hashbang or shebang if you like, but understand that only the hash is of significance.
The actual term "shebang" or "hashbang" goes back a lot further, and does refer to a #! syntax, but not in the context of a URL.
The original meaning of this term was where these symbols were used at the beginning of a Unix script file, to tell the script processor what programming language the script is written in.
So this is indeed an answer to your question, the way you've worded it, but is probably not what you meant, since it has nothing to do with URLs at all.
I'm having the strangest issue with codeigniter. I have a site that has a search feature which displays the person's query in the url so that they can save the url. I make sure that the query text has gone through rawurlencode before I stick it in the url. However, Codeigniter still shoots me to an error page when there's a character in the query that isn't in my permitted_uri_characters configuration.
So even though my browser says /search-results/query/%22samplequery%22, I’m still getting the error about using non-permitted characters.
Is this a bug? I don’t have non-permitted characters in my url. I have a % sign and some numbers (which are all specifically permitted). It’s definitely the permitted_uri_characters setting that’s giving me grief. If I add a quotation mark to it, it allows the %22 query through no problem.
And to be clear, the query is coming from a form as post data, then being encoded in my controller and then redirected to a new page. There’s no way that the permitted_uri_characters is somehow being applied BEFORE it gets encoded.
This is driving me batty, as my only solution at the moment is to open up my permitted_uri_charcters to everything under the sun, which isn't very secure!
Seems like you'd need to add # to the permitted_uri_chars, even if you urlencode the email before sending it to site_url(). Might urldecode it before watching up the characters ...
Percent Symbol in CodeIgniter URI
Here is a post more specific to your problem.
http://sholsinger.com/archive/2009/04/passing-email-addresses-in-urls-with-codeigniter/
I tried with the permitted_uri_chars, and finally ended up passing the email as a query string (?email=bla#bla.com), not even urlencoding it. Works great :)
Could it be URL encoding the %20 to a " before codeigniter verify' it? How about adding that to the permitted char's list.
I have my own solution for this, it's messy and not optimal, but it works. You can create a table where you store (search_string , url_title).
Every time you perform a search, save the string, generate an url_title() and save it to the database. This way, you can redirect your user to a safe url, without missing the initial search.
I know somebody is gonna yell at me for this solution. But, if your site is small, and your traffic keeps low, it's a valid solution.
In Linux Firefox, if in case there is any error related to SSL/TLS, which source file does it refer to in order to generate the error code and pop up window (or error page)?
It's still not clear what exactly you're looking for since the implementation behind this is scattered among many source files, but I'll show you how to start.
Mozilla has MXR, which can be used to quickly search through their code. So we take the caption of a visible element on the page you're interested in, e.g. "I understand the risks" button and search for it: http://mxr.mozilla.org/mozilla-central/search?string=I%20understand%20the%20risks. You find the only hit, which defines the string and you'll need to search again to find where that string is actually used: http://mxr.mozilla.org/mozilla-central/search?string=certerror.expert.heading.
This gets us to http://mxr.mozilla.org/mozilla-central/source/browser/components/certerror/content/aboutCertError.xhtml which falls under the definition "Source file for Firefox’s SSL error", but may be not the end of your journey :)