I would like to provide extended RSS content (extended with unmoderated comments, for example) to premium users (moderators).
Would it be possible to somehow authenticate readers of feeds other than attaching a personal token string to the RSS URL?
Granted, this way a curious person only needs to steal an RSS link like this (much like one could steal a session id), but a password could be acquired just as easily, right?
How could I make this a bit more secure especially against PEBKAC issues?
Would you consider this an idea worth pursuing or should I just discard it and find some alternative? Could you suggest such an alternative?
You can use http authentication, like this java example.
It, and your url idea, are in the open, so https is needed to prevent user/pass/session theft.
You would then also need user and session code, and password recovery code. You could try advertising before doing the work. Create a link, "Click here to pay X dollars for premium rss", and see if anyone uses it. I think there was a stack overflow podcast that mentioned this, anyone remember which one?
Related
The limitations of the Google+ API have just put a hold on a little project I am working on.
I can achieve what I need with a basic cURL script (login to Google+ Page, scrape page, parse data) but I was just wondering if this is allowed?
(yes the script will break whenever they update G+, I can live with that)
A search on "are you allowed to login to google with curl" produces lots of results. So it seems lots of people are doing it, just wondering if anyone knows if it is "really" allowed?
I am not a legal attorney, always seek advice from law professionals.
However my take on this is that it is legal. Nothing restricts you from crawling websites and performing datamining without wasting the resources of the server (Such as DDOS) and without using any illegal means to attain this information such as exploiting the server software or using some vulnerability that might expose the user data.
If this information is publicly available online it belongs to the Public Domain, and as long as you are not selling it, it can be considered fair use.
On the other hand you are violating an awful lot of user agreements.
Is it possible to use Mailchimp API to subscribe emails to the lists of MY USERS' Mailchimp Accounts and not my own?
Basically I have a web app, and users collect emails of various subscribers through this app. I then want them to be able to click a button and subscribe all those emails to their lists.
I've looked at Mailchimp's API - particularly the /lists/subscribe and the /lists/batch-subscribe methods. However so far it appears that these will only work for your own Mailchimp account and not for remote users' accounts.
Can someone please tell me whether what I'm trying to achieve is possible with Mailchimp's API?
You would need to execute the api-calls with your users' api-key, which would mean that you execute the calls with their credentials.
There are three different ways to get their api keys, with different practicality levels.
You guess. They look like guids without dashes, and some information about which datacenter it is associated with. Some easy (and somewhat bad) calculations indicate that there are 2^128 api keys in every datacenter, so this will consume both cpu- and network-resources, and invoke the rage of the Mailchimp. The linked image shows him on a good day. He won't be as pleasant if you choose this alternative. Dont do this.
You ask, in an evil way, for their username/password. This is bad since it will give you to all accounts those credentials works with. This would also give you access to stuff that aren't available using api calls (like payment stuff). This wont work at all if your user is intelligent administrators that are using AlterEgo, the two-factory security alternative. This alternative is less bad than blindly guessing, but still provides too much access, if it works at all.
You ask, in a user-friendly way (with perhaps some quick tutorials), for the user to generate an api-key in mailchimp to provide to you. This is the Good Alternative (tm).
You may choose any implementation as long as you choose number three.
In particular I'm interested in the possibility of getting an App Access Token with no expiration time, exactly as I do with Facebook.
I want to publish on behalf of the user via server, and I found very useful and convenient the Facebook's procedure in which we ask for the user permissions only the first time.
I have been working with this kind of social-networks interaction for merely three weeks, so I will be very happy to hear any type of suggestions or critics.
Google+ does not currently have a public write API. There are selected partners that they work with (such as HootSuite) that provide this feature, but they are making access to it available very slowly. See https://developers.google.com/+/api/pages-signup for further details.
Google+ does have a concept of Moments, which are activities that happen in your app that are reported to Google+ and which the user may later wish to share, or may make available to people in their circles on a limited non-notification basis. This is probably not what you want, but may serve some needs. See https://developers.google.com/+/api/latest/moments for more info and examples how to use it.
Simply, No there is no way to do that in Google+ in current time. In general, apps for Google plus is read only.
After significant voodoo, I have finally got the scores API working. Turns out you have to set Enhanced Auth Dialog to disabled or Facebook ignores your publish_actions permission. Just a heads up in case anyone else is struggling.
However, I'm working entirely in the Javascript API. No server-side scripting is available.
The only way to publish a score is with an app access token. The only way to get one of them is to use the app secret, and that would have to be in the javascript code for the world to see. How bad is that exactly?
TBH I don't care if someone spoofs the scores to my little pong-style games. Good for them, only them and their friends can see it. It's just a bit of fun. But what exactly can go wrong if my app secret is published? Can someone hijack the entire application? Or is it just bad practice and nothing much can go wrong with a little mini game?
It's all purely javascript SDK so it seems to work only by user access tokens, so my first instinct is it's OK. But I thought I'd ask....!
What other permissions are you using? If you're using "publish_stream" I'm sure you could imagine the shenanigans that could ensue! Even worse, if the user has both your public and private key (which they will) they could create an entire spoof application that identifies itself as you!
The "domain" options in facebook should prevent this, but if there's any chance an attacker could do an XSS attack they could potentially write malicious apps that masquerade as your game.
Have you considered writing something very simple with google app engine for the sole purpose of dealing with the app authentication token?
I'm building a utility that will hopefully keep my wife in tune with how much money we have available.
I need a simple secure way of logging into my bank account and retrieving the balance.
Something like mechanize is the only method I can think of. I'm not even sure if that would work given the properly authenticated https that banks use.
Any ideas?
Write a perl script using LWP::UserAgent. It supports HTTPS connections. The only issue might be if the site requires javascript.
Web Client Programming with Perl has a few examples to get you started if you're not too familiar with perl.
If you really want to go there, get these extensions for Firefox: Live HTTP Headers, Firebug, FireCookie, and HttpFox. Also download cURL and a scripting language that can run cURL command-line tasks (or a scripting language like PHP or Perl that has access to cURL libraries directly).
I've started down this road for some idempotent GET tasks like getting PDFs of the S&P reports (of the stocks I track) from my online brokerage, and downloading the check images for my bank account. Both tasks are repetitive and slow ways of downloading data to my computer that the financial institutions don't provide any way of making it easier.
Here's why you shouldn't: (as a shortcut I'm going to call the archetypal large bank, brokerage, or other financial institution "BloatBank")
BloatBank is not likely to make public their API for accessing this kind of information. So it can change any time and all your hard work will be for naught. Whenever they change their mechanism, you'll have to adapt.
If BloatBank finds out you've been using automatic scripting to try to access your account information, they may ban you because you've violated their terms of service.
You might screw up, and the interaction between the hodgepodge of scripts on BloatBank's server, and your scripts that access your account, might cause a Bad Thing like closing your account. Testing this kind of script is tremendously difficult because you don't have any documentation about how their online service works, and you don't have a test account you can mess with.
(a variant of the above) You think you're safe because you're issuing GET requests. But BloatBank is just a crazy bank that doesn't know anything about REST, so there are some GET requests that can mess up your account.
If someone else does use your script to maliciously sniff your online password or mess with your account, any liability coverage from BloatBank may disappear because you've opened a security hole.
Why don't you teach your wife how to login to the bank herself? Or use Quicken (or Mint, etc) and teach her how to use the auto-download feature?
Have you checked out Watir? It is fantastic for automating web-browser actions. And since it's written in Ruby, you can take the results and store them in a DB (or email them to yourself) if needed.
If you are open to AIR, I'd say build an AIR app. I have worked with mechanize and I think it's cool. AIR gives you similar features with a richer GUI (see HTMLLoader and DOM manipulation of webpage).
If I were you, I'd simply pull the page and manipulate the DOM to suit my visual needs.
Please, if you find this easy to do for your bank please post your bank's name. If I have the same one I'll be closing my account.
More to your question. The process of loading a web page inside of your code rather than in a browser can be a black art, especially if their is any javascript involved. Your best bet would probably be embedding the IE Web Browser control in your app and then simulating key strokes and mouse clicks to arrive at your balance page. Then scrape the HTML for the balance.
I could try paying for Quicken and letting it do the balance downloading. Then I'd just need to find a way to get the number out of the software automatically.
This way I'm not violating any terms of service and I'm also reducing security risk since all "hacking" goes on locally.