My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
Suppose you have some awesome analytics tool that provides great value to a bank's customer, but they need to interact with it through the bank's website, and you need to host the tool.

You already have the data you need for the analytics to work, and the only missing piece you're left to consider is "how do I know to whom to show which data?"

The data is private, so you need to ensure you're not showing it to someone who's not authorized to see it.

An insecure lock
Photo by pbkwee

Some more constraints:
  • You don't want to generate thousands of usernames and passwords that would create more burden for the users (and force them to log in twice)
  • You can't hook into the bank's user system. (nor would you want to, since they'd still have to log in twice)
  • You want this to be reasonably simple for the bank to implement whatever they need to do to make it work on their end.
To show it on their site, you decide to create a template-less app that they'll embed in an iframe.

So what authorization mechanism do you use to know who should see which data?

One idea I had was to simply restrict which IP addresses (to those of the bank) the app would respond to. Then they could just request a page via HTTP and serve up our response. But in order to get that to work, there's too much that needs to be done: we have to coordinate all URLs with whatever the bank decides they should be, and they have to figure out whether to GET, POST, PUT, etc. back to us.

The next idea was to have a single page that is restricted by IP address (to those of the bank), where they will make an HTTP request to receive a token that expires after some length of time (or at the bank's request, if they hit another URL to invalidate the token). The bank includes the token in the iframe src URL which lets you know whose data to show.

But I'm really interested in hearing your thoughts. How would you do it? Is there a standard way of doing this already?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Leave a comment

When user log in he gets token, on every request you pass token as parameter and based on token you decide will you return wanted info

Posted by Rocco on Dec 09, 2011 at 12:43 PM UTC - 6 hrs

The problem I see there is that anyone who got that link now has a valid token, and can then see info they shouldn't be seeing.

Posted by Sammy Larbi on Dec 09, 2011 at 01:18 PM UTC - 6 hrs

I considered OAuth, but felt it would be too much hassle for the bank in this case to be their own OAuth provider.

However, after a little prodding from one of my friends on twitter, I did some looking and it seems there are enough libraries out there for server and client side that it might not be as much work to become their own provider as I originally thought.

Still interested in hearing more suggestions though!

Posted by Sammy Larbi on Dec 09, 2011 at 01:20 PM UTC - 6 hrs

I would have to second Oauth.

Have you looked into how Wesabe did it? They opensourced a lot of the code when they went belly up.

Posted by SeanJA on Dec 19, 2011 at 11:12 PM UTC - 6 hrs

Cool, I didn't realize Wesabe open sourced their stuff.

For anyone who's interested, see

However in my case, "bank" is just a dummy system to stand in for "a place where the data needs to remain secure, because it's very sensitive."

Posted by Sammy Larbi on Dec 20, 2011 at 05:52 AM UTC - 6 hrs

Well, it's a difficult question. Personal data protection is an important issue web developers have to deal with nowadays. There a variety of techniques they could use. There are a few of them I could recommend, but I'm not sure I can share my knowledge here.

Posted by microsoft dynamics ax on Jul 28, 2016 at 02:40 AM UTC - 6 hrs

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner