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.
Related
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?
I'm just learning ASP.NET using VB 2010, and although I've had a lot of good progress, I am stumped by one issue that I can't resolve. I've also the web for answers, but I haven't found anything that is exactly what I am dealing with. ...though I may not be using the correct search terms.
Anyway, this is an app that will run on our company internet site which requires users to enter information into text boxes and click a button to accept it. Then it will show a modal pop-up asking the user to confirm. The pop-up has a "Confirm" button and a "Cancel" Button. The cancel button works immediately (hides the confirmation pop-up), but the confirm button hangs up for several seconds before it moves to the next step, which is a modal "Thank You" pop-up. The Confirm button writes data to a database.
Now, that's how it works inside the development environment. However, when it's on the production server, it will sit there for who-knows-how-long before it does anything. I can tell that it is writing to the database, and then displaying the data on the page, but the Confirmation pop-up stays up, and the Thank You pop-up never shows up. Also, the app is supposed to send an email to the user as acknowledgement, but it doesn't do that.
When it hangs up like this, I have never waited long enough to see when it catches up. And when it's live like that, I don't know of a way to debug it.
More info about the page: There are several update panels, one that responds to a timer tick every second to update fields on the page. The others are set to "conditional," being updated by other events. For example, the Confirmation and Thank You modals are in conditional update panels which respond to different events.
So I have two questions: Can anyone advise me about the hangup, and is there a way to debug from a live site? Oh, and maybe a third: Can you have too many update panels?
Update: Follow up question: Can it be going off on a different thread, going off track from the correct thread? I've never really understood threading, but this seems like a possibility.
This could be any number of things, so it's going to probably be something you're going to need to dive into and troubleshoot and it's probably not something we'll be able to help with too much.
First, the obligatory request: please post your code :)
Now, something that works quickly and dev and slowly in production is usually a resource issue or a code/data issue. First, take a quick look at the server and make sure it's up to the task for multiple users and all of that. It's worth a quick look, but it's usually an issue with the code or data.
What is that update command doing? Is the SQL behind it written well and efficiently? Are there any database locks that might be happening where another user is doing something and your code is actually waiting for it to complete before doing the updating? How many rows are in the database / how many are being effected?
I'd start by running a SQL trace to see what's really happening and to get an ideas as to how many database calls there are an how long each one takes to execute. If that's not the answer, look at the VB code and see if it's efficiently written. If not, go back to the server resources. Without seeing any code or having any idea what the application is supposed to do, I'd bet on the database queries being the culprit.
My bad. I hadn't mentioned one aspect, because I had no idea it would be a factor, but it is. Part of the process was to log certain events into a log file. The way it's set up in our IIS, that's a big no-no. So it was throwing an error, but the error was only manifesting itself as a long delay. I commented out the code that opens, writes to, and closes the log file, and it's all good.
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.
I notice that when I try to access Stackoverflow through the reddit toolbar, I get a popup that says "For security reasons, framing is not allowed". See here for an example.
What exactly are those security reasons?
I realize that this might be a question for meta, but it is really more of a general web security question, so I'm giving it a shot here.
Thanks.
You can check the story on that in here.
EDIT:
Ok, so quoting from the link the problem with framing is that it's the first step to clickjacking. How is that accomplished? You can have an apparently harmless page with links which have on top of it a frame with full transparency that was carefully positioned so that when you click the links of the page, you'll be clicking links or buttons of the framed page. Although you can't see the frame (due to full transparency), your clicks will be caught by it. This results in, while the user is lead to thinking that he's just navigating on a random page, he may be actually changing his twitter status, sending emails, doing something on facebook, clicking a paypall "Yes please donate it all" button, ... imagination is the limit.
To protect its users from click jacking attacks. In simple words click jacking works like this:
The attacker hosts the malicious html file
This file loads the 'attacked' website in the background using a frame and by overlaying elements on top of the 'attacked' website it tries to trick the users into clicking something they didn't want to.
If an evil website decides it's going to frame your website, you will be framed. Period
Wrong. Mechanisms like the one implemented here in stackoverflow protect websites from being loaded inside another possibly malicious page. This way the site protects its users against click jacking attacks.
f that is the case, why do it at all? Furthermore, the target of the attack is not necessarily the site being framed, it could be any site. So again, why bother busting the frame?
The frame is used to load the 'victim's website inside a page that will try to trick the users. Busting the frame means that the site is blocking these possible click jacking attacks. Or at least adding an extra layer of security since these 'filters' can also be bypassed.
Read the original research paper about click jacking
Apparently there is a tiny chance of a possible click-jack attack as demonstrated here:
http://dsandler.org/wp/archives/2009/02/12/dontclick
So I guess it kinda makes sense, but it is awfully inconvenient.
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. :)