One of the purposes of og:url -- I thought -- was that it was a way you could make sure sessions variables, or any other personal information that might find its way into a URL, would not be passed along by sharing in places like Facebook. According to the best practices on Facebook's developer pages: "URL
A URL with no session id or extraneous parameters. All shares on Facebook will use this as the identifying URL for this article."
(under good examples: developers.facebook.com/docs/sharing/best-practices)
This does NOT appear to be working, and I am puzzled as to either -- how I misunderstood, and/or what I have wrong in my code. Here's an example:
https://vault.sierraclub.org/fb/test.html?name=adrian
When I drop things into the debugger, it seems to be working fine...
https://developers.facebook.com/tools/debug/sharing/?q=https%3A%2F%2Fvault.sierraclub.org%2Ffb%2Ftest.html%3Fname%3Dadrian
og:url reads as expected (without name=adrian).
But if I share this on facebook -- and then click the link. The URL goes to the one with name=adrian in it, not the og:url.
Am I doing something incorrectly here, or have I misunderstood? If the latter, how does one keep things like sessions variables out of shares?
Thanks for any insight.
UPDATE
Facebook replied to a bug report on this, and I learned that I indeed was reading the documentation incorrectly
developers.facebook.com/bugs/178234669405574/
The question then remains -- is there any other method to keeping sessions variables/authentication tokens out of shares?
Related
I want to track particular links on my site to see where they come from. For example, I want to know which links on my navigation are being clicked, so if something is not being clicked I could potentially remove it.
I have been using UTM's, super easy, but results in skewed analytics data.
I looked into Google Tag Manager, but I don't want to slow down my website. I can change the site easily, so not sure if this is the best solution.
I found an article dated 2008 that says I can do this:
https://www.example.com/?from=topnav
Is that still valid? Is there a better way. I can't seem to find any information on this and assume somebody wants to acquire this information.
Thank you.
I have been using UTM's, super easy, but results in skewed analytics
data.
UTM codes are meant to track inbound traffic. Don't use them to track internal/outbound navigation, as it will seriously mess up your reporting.
I looked into Google Tag Manager, but I don't want to slow down my
website.
GTM is loading async, just like GA, so performance-wise they are equivalent.
I found an article dated 2008 that says I can do this:
https://www.example.com/?from=topnav
By default GA will not track link clicks. You can indeed add parameters to URLs and then use those to build custom reports and see which links are being clicked.
Since what you're trying to do is custom implementation, you won't find a single best answer, it's up to you to implement something that fits your needs. These are some examples:
https://analytical42.com/2017/track-internal-links-google-analytics-gtm/
https://www.gravitatedesign.com/blog/can-google-analytics-track-link-clicks/
What people are doing is basically taking the UA-XXXXXX code that you normally get with analytics, and they are generating calls against it. This is skewing my analytics stats. On top of that, in Google WebMaster tools, it's also causing this:
It looks like somehow these pages, with my code on or at least with the generated code on, is making Google Webmaster tools think I have lots of 404's. This can't possibly be good for my rankings.
Anyone know if there is anything you can do to stop this?
Try making async call from your server end using CURL.That way you will never expose your GA code.
I have not implemented it, but it might work as per theory
Since you can filter by custom dimensions you can set a "token" in a custom dimension on every page and filter out any traffic in your view settings that does not include the token.
Obviously this will not help against people who use the code from your website (unless you also implement shahmanthan9s suggestion - which is a lot of work but will give you cleaner data), but it will work against drive-by shooters who randomly select UAIDs to send data to (which is the situation you refer to in your comment).
Currently reading Bloch's Effective Java (2nd Edition) and he makes a point to state, in bold, that overusing POSTs in web applications is inherently bad. Unfortunately, he doesn't specify why.
This startled me, because when I do any web development, all I ever use are POSTs! I have always steered clear of GETs for security reasons and because it felt more professional (long, unsightly URLs always bother me for some reason).
Are there performance differentials between GET and POST? Can anyone elaborate on why overusing POSTs is bad, and why? My understanding - and preliminary searches - seem to all indicate that these two are handles very similarly by the web server. Thanks in advance!
You should use HTTP as it's supposed to be used.
GET should be used for idempotent, read queries (i.e. view an item, search for a product, etc.).
POST should be used for create, delete or update requests (i.e. delete an item, update a profile, etc.)
GET allows refreshing the page, bookmark it, send the URL to someone. POST doesn't allow that. A useful pattern is post/redirect/get (AKA redirect after post).
Note that, except for long search forms, GET URLs should be short. They should usually look like http://www.foo.com/app/product/view?productId=1245, or even http://www.foo.com/app/product/view/1245
You should almost always use GET when requesting content. Only use POST when you are either:
Transmitting sensitive information which should not appear in the URL bar, or
Changing the state on the server (adding/changing/deleting stuff, altough recently some web applications use POST to change, PUT to add and DELETE to delete.)
Here's the difference: If you want to give the link to the page to a friend, or save it somewhere, or even only add it to your bookmarks, you need the full URL of the page. Just like your address bar should say http://stackoverflow.com/questions/7810876/abusing-http-post at the moment. You can Ctrl-C that. You can save that. Enter that link again, you're back at this page.
Now when you use any action other than GET, there is simply no URL to copy. It's like your browser would say you are at http://stackoverflow.com/question. You can't copy that. You can't bookmark that. Besides, if you would try to reload this page, your browser would ask you whether you want to send the data again, which is rather confusing for the non-tech-savy users of your page. And annoying for the entire rest.
However, you should use POST/PUT when transferring data. URL's can only be so long. You can't transmit an entire blog post in an URL. Also, if you reload such a page, You'll almost certainly double-post, because the above described message does not appear.
GET and POST are very different. Choose the right one for the job.
If you are using POST for security reasons, I might drop a mention of other security factors here. You need to ensure that you send the data from a form submit in encrypted form even if you are using POST.
As for the difference between GET and POST, it is as simple as GET is used to send a GET request. So, you would want to get data from a page and act upon it and that is the end of everything.
POST on the other hand, is used to POST data to the application. I am talking about transactions here (complete create, update or delete operations).
If you have a sensitive application that takes, say and ID to delete a user. You would not want to use GET for it because in that case, a witty user may raise mayhem simply changing the ID at the end of the URL and deleting all random uses.
POST allows more data and can be hacked to send streams of files as well. GET has a limited size though.
There is hardly any tradeoff in using GET or POST.
Alright, I fear I may be critiqued for this not being so much of a "programming" question, but I'll ask anyway. I don't do to much in web development-type stuff (OO is what I stick with mostly), so I'm not too keen on exactly how all this CSS, Javascript, SQL, etc works.
The problem: My friend has been trying to quit smoking for a while, but as many smokers do, he seems to only make it so far. He recently posted a status update saying if he had the moral support, he could do it. I simple want to create a link to the "Like" button. I then intend to write a script and simple message all his friends with the link. Is this possible?
Any tips in the right direction would be greatly appreciated. An explanation of how to do this would be divine. An explanation of why I can't do this would be met with a scowling acceptance and a thank-you.
For those who don't have a facebook, here are some pastebins. Anything else you need I'll try to supply
Pastebin of a my facebook.com/homepage page source:
http://paste.uni.cc/19860
Pastebin of his homepage as I see it page source:
http://paste.uni.cc/19860
His update to ctrl+F and see surrounding code:
"would quit smoking if he had the moral support."
Thing that looks to me like the css code for the "like" command
http://static.ak.fbcdn.net/rsrc.php/z2FUI/l/8fkujrwg/en_US/151675/css/like/like.css
Will this stop him from smoking? Most likely not, but it can't hurt. Worst case he'll just get a laugh and maybe feel a bit more inclined to drop the cigs.
Appreciate it as always.
The "Like link" is a Javascript-backed element which invokes an AJAX call to the server. It carries a unique ID which is keyed off both the item being "liked" and the user who pulled down the page (in this case, you) to ensure duplicate "likes" are not accidentally submitted and the UI to become out of sync with the DB; and to ensure you can't "like" something on another user's behalf. The case you are describing is indiscernible from a malicious attempt at doing the same thing.
Can you just send them a message with a link to the friend's page and tell them to "Like" the status themselves?
Why not write a Facebook application and plug directly into your own profile. You could invite his friends to your application, which would allow them to support your friend's attempt to quit smoking without having to hack together a script that "clicks" the Like link. The hack could easily be considered malicious.
I have an ASP.Net application which as desired feature, users would like to be able to take a screenshot. While I know this can be simulated, it would be really great to have a way to take a URL (or the current rendered page), and turn it into an image which can be stored on the server.
Is this crazy? Is there a way to do it? If so, any references?
I can tell you right now that there is no way to do it from inside the browser, nor should there be. Imagine that your page embeds GMail in an iframe. You could then steal a screenshot of the person's GMail inbox!
This could be made safe by having the browser "black out" all iframes and embeds that would violate cross-domain restrictions.
You could certainly write an extension to do this, but be aware of the security considerations outlined above.
Update: You can use a canvas utility function to get a screenshot of a page on the same origin as your code. There's even a lib to allow you to do this: http://experiments.hertzen.com/jsfeedback/
You can find other possible answers here: Using HTML5/Canvas/JavaScript to take screenshots
Browsershots has an XML-RPC interface and available source code (in Python).
I used the free assembly UrlScreenshot.dll which you can download here.
Works nicely!
There is also WebSiteScreenShot but it's not free.
You could try a browser plugin like IE7 Pro for Internet Explorer which allows you to save a screenshot of the current site to a file on disk. I'm sure there is a comparable plugin for FireFox out there as well.
If you want to do something like you described. You need to call an external process that prints the IE output as described here.
Why don't you take another approach?
If you have the need that users can view the same content over again, then it sounds like that is a business requirement for your application, and so you should be building it into your application.
Structure the URL so that when the same user (assuming you have sessions and the application shows different things to different users) visits the same URL, they always see same thing. They can then bookmark the URL locally, or you can even have an application feature that saves it in a user profile.
Part of this would mean making "clean urls", eg, site.com/view/whatever-information-needed-here.
If you are doing time-based data, where it changes as it gets older, there are probably a couple possible approaches.
If your data is not changing on a regular basis, then you could make the "current" page always, eg, site.com/view/2008-10-20 (add hour/minute/second as appropriate).
If it is refreshing, and/or updating more regularly, have the "current" page as site.com/view .. but allow specifying the exact time afterwards. In this case, you'd have to have a "link to this page" type function, which would link to the permanent URL with the full date/time. Look to google maps for inspiration here-- if you scroll across a map, you can always click "link to here" and it will provide a link that includes the GPS coordinates, objects on the map, etc. In that case it's not a very friendly url but it does work quite well. :)