When I was working with angular cookies, I found out that only strings are accepted by $cookies and stored in browser's cookie when set. i.e
If I set the following cookies
$cookies.id = 12345;
$cookies.name = "Prasad";
Only $cookies.name is set in the browser. So I had to change it to
$cookies.id = "12345";
to make it work.
here is the fiddle link to show the demo.
I've tried to check the angular source code to see why and found that they are deliberately checking for the value to be isString.
Is there any specific reason why they are accepting only string values. Couldn't we just allow integers also and convert to string while adding to browser cookie.
Thanks!
The main reason is probably that that the value of a cookie is always stored as a string in the browser. Sure, Angular could allow you to save it as an int when using the service and then just convert it before creating the cookie, the problem is that people would then assume that when they read that cookie later on the value would still be an int (that's how they saved it after all).
It wouldn't, it would be a string.
Angular seems to reason (I personally agree) that it is better to be strict up front. Force input to be the same as output so that people don't misunderstand what they will be getting back when they read the cookie.
Related
I'm trying to load an external page using JSONP, but the page is an HTML page, I just want to grab the contents of it using ajax.
EDIT: The reason why I'm doing this is because I want to pass all the user information ex: headers, ip, agent, when loading the page rather than my servers.
Is this doable? Right now, I can get the page, but jsonp attempts to parse the json, returning an error: Uncaught SyntaxError: Unexpected token <
Sample code:
$.post('http://example.com',function(data){
$('.results').html(data);
},'jsonp');
I've set up a jsfiddle for people to test with:
http://jsfiddle.net/8A63A/1/
http://en.wikipedia.org/wiki/JSONP#Script_element_injection
Making a JSONP call (in other words, to employ this usage pattern),
requires a script element. Therefore, for each new JSONP request, the
browser must add (or reuse) a new element—in other words,
inject the element—into the HTML DOM, with the desired value for the
"src" attribute. This element is then evaluated, the src URL is
retrieved, and the response JSON is evaluated.
Now look at your error:
Uncaught SyntaxError: Unexpected token <
< is the first character of any html tag, probably this is the start of <DOCTYPE, in this case, which is, of course, invalid JavaScript.
And NO, you can't use JSONP for fetching html data.
I have done what you want but in my case I have control of the server side code that returns the HTML.
So, what I did was wrapped the HTML code in one of the Json properties of the returned object and used it at client side, something like:
callback({"page": "<html>...</html>"})
The Syntax error you are facing it's because the library you're using expects json but the response is HTML, just that.
I've got three words for you: Same Origin Policy
Unless the remote URL actually supports proper JSONP requests, you won't be able to do what you're trying to. And that's a good thing.
Edit: You could of course try to proxy the request through your server …
If you really just want to employ the client to snag an HTML file, I suggest using flyJSONP - which uses YQL.. or use jankyPOST which uses some sweet techniques:
jankyPOST creates a hidden iframe and stuffs it with a form (iframe[0].contentWindow.document.body.form.name).
Then it uses HTML5 (watch legacy browsers!) webMessaging API to post to the other iframe and sets iframe's form elements' vals to what u specified.
Submits form to remote server...done.
Or you could just use PHP curl, parse it, echo it, so on.
IDK if what exactly ur using it for but I hope this helps.
ALSO...
I'm pretty sure you can JSONP anything that is an output from server code. I did this with ClientLogin by just JSONPing their keyGen page and successfully consoleLogged the text even though it was b/w tags. I had some other errors on that but point is that I scraped that output.
Currently, I'm trying to do what you are so I'll post back if successful.
I don't think this is possible. JSONP requires that the response is rendered properly.
If you want another solution, what about loading the url in an iframe and trying to talk through the iframe. I'm not 100% positive it will work, but it's worth a shot.
First, call the AJAX URL manually and see of the resulting HTML makes sense.
Second, you need to close your DIV in your fiddle example.
I am surprised that when I submit a variable with an identical string value it is rejected when the string is accepted in google oauth
For example
$client->setClientSecret('xDDDDDDD-Tcdfgtrrfftr');
is accepted where with the same string value stored in the variable as follows
$client->setClientSecret('{$domain->GooglePlusSecret}');
is rejected.
Anyway to write this to get around it? I serve multiple domains through the same root folder and software and want to set up for individual oauths as well ???
I'm assuming you're using PHP here, since that's what your code looks like.
Single quoted strings do not have variables interpreted. The reason your OAuth token doesn't work is because you are using the literal string {$domain->GooglePlusSecret}.
You should change your code to either $client->setClientSecret($domain->GooglePlusSecret); or $client->setClientSecret("{$domain->GooglePlusSecret}");.
I am sending a signup activation email containing a signup confirmation url with a confirmation token that points to an angular front end app:
...
Activate
...
Note that the token is a JWT and is fairly long.
This works find for most users, but for some clicking on the link takes them to https://domain/com only without the confirm-signup?token=...
It seems as though the mail client may be stripping off everything after the #, but I can't find any evidence of others having this problem, nor can I reproduce it.
My best guess so far is that some mail clients are seeing the # and somehow treating the trailing part as an internal anchor and stripping it...?
Has anyone else encountered this sort of problem? If so, have you found any solution short of replacing the whole mechanism with something else?
Some clients treat the hash-link just fine. Others don't. There's a conversation about Outlook being dirty about this here: Outlook strips URL hash from email
What we did to resolve this at our company is simply create a handler on our server that redirects. Your email link would become http://domain.com/email-link?url=https%3A%2F%2Fdomain.com%2F%23%2Fconfirm-signup%3Ftoken%3D1234 and your server side script would grab the query param url and immediately trigger a redirect.
You'd need to make sure that you find all links in your emails and replace them. Here's a PHP function for that, but you could do this in whatever backend language you're using. Regex here may be helpful at least.
function replaceLinks($html,$hash) {
return preg_replace_callback('/<a [^>]*href=[\"\']{1}(.+?)[\"\\\']{1}/', function($matches) use ($hash) {
return str_replace($matches[1],"http://domain.com/email-link?url=".rawurlencode($matches[1]),$matches[0]);
}, $html);
}
Yes I have encountered this issue before because of the #, I was trying to link to a anchor on a landingpage.. My solution ended up using a short.url service to "hide" the # from the html e.g. https://goo.gl/
Looks like you need percent encoding!
A lot of times when your href gets parsed (by angular in this case) it doesn't handle the special characters right, or strips them. Find your problem characters and replace them with %3F for ?, %26 for &, and %23 for #. The rest are in a chart in the link.
Once the encoded address hits the browser the url will be decoded in your url bar.
I'm running an app with Sinatra/backbone.
Let's say I visit the page http://localhost:3000/cases/1/read?name=Some%20Guy that is using the name parameter to display data on the page.
Does this present an XSS issue?
I'm just trying to send data from one page to another through a button click with the param data.
A quick test is to try the URL
http://localhost:3000/cases/1/read?name=<script>alert('foo');</script>
If the script executes and an alert popup appears, then XSS is definitely possible.
Other XSS patterns are possible too depending on where the name value is output.
You should output encode to prevent this type of attack. The encoding to use depends on the language context of your output (if is it JavaScript, HTML, or CSS, etc). e.g. " becomes " in HTML, but \x22 in JavaScript and JSON. The correct encoding prevents an attacker being able to escape out of the context and inject their own scripts. You should also set the charset to UTF-8 to prevent some UTF-7 filter evasion attacks.
Not necessary. All dependence on which way data shows to user. If you keep in mind, that data can be wrong and for example escape string before output - it will be ok.
I have a C/CGI application. In order to redirect to the same page
const char * redirect_page_format =
"<html>\n"
"<head>\n"
"<meta http-equiv=\"REFRESH\"\n"
"content=\"0;url=%s\">\n"
"</head>\n"
"</html>\n";
printf (redirect_page_format, getenv (URL));
Before this the url is like this "http://ipaddress/page.html".
For some pages, I am able to redirect correctly.
But some html pages,
The url is either appended with a character like this "http://ipaddress/page.htmlP"
Or the url is changed like one of the following:
http://ipaddress/page.htm
http://ipaddress/page.hX
Edit 1
I will send the url through query string. It will be got using the command.
getenv("QUERY_STRING")
By parsing the query string, url can be got and it is given as an argument to redirect command.
printf (redirect_page_format, getenv (URL));
I can't see anything that would cause that in the above code. Sounds like some wayward pointer writing somewhere else in the script might have written data to corrupt the end of the variable string?
What is getenv(URL) anyway? There isn't a standard CGI environment variable that gives you the current URL; you usually have to tiresomely piece it together from REQUEST_METHOD/HTTP_HOST/SERVER_PORT/SCRIPT_NAME/PATH_INFO/QUERY_STRING. On Apache you do get REQUEST_URI but it won't work on other servers.
Whilst it wouldn't usually cause the problem you quote, there is an issue with printfing text into an HTML context like you have above: you don't have any HTML-escaping, so any &, " or < characters in the URL will cause invalid output. Every time you add text or attribute value content from a string you must HTML-escape it, or you risk a cross-site-scripting security hole. (" and < are unlikely to exist in a URL but can get there depending on how you're handling SCRIPT_NAME/PATH_INFO. & is very likely to appear in the URL.)
Finally, <meta refresh> for redirect is highly undesirable. Why not a proper Location-based redirect?