I'm trying to learn the development of Web Applications in JavaScript, and for this I am developing a simple Time Tracking application. I am developing this with ExtJS for dynamically creating the UI.
This would allow Employees to submit the time they have spent working on different projects, and allow the Managers, to add Projects to Users and so on.
Once the user signs in, I determine their role, and provide the appropriate UI (through JavaScript).
I was wondering what is the best and most secure way of doing this? (I am of course checking the authorization on the server side, so that no one can make changes by just calling my PHP Services via http get/post)
I asking from a perspective of disallowing a non authorized person, to even see the non-authorized UI, by fiddling with the JavaScript (from the FireBug console for example).
I was thinking of creating a Service which returns the appropriate script for creating the appropriate UI, through JSONP. It feels quite WTF-ey to me, so I was wondering if there was better way.
To build on naugtur's comment. You must always assume that there will be a very smart person that can build the UI for himself/herself, or fake any of the calls to the server that any part of the UI could do.
Based on that, the premise of the way you suggested towards the end of your question seems debunk to begin with. The easiest route once we settle that (I'm assuming your making a single-page application) would be to always dump all the javascript code right up front at the login screen and only allow the user to see what they need to based on their role (i.e. a card panel that has different cards for each role would be an example).
I would also like to add that on the backend of the application, you should always have security checks in place to make sure the user has the correct role for whatever action he is doing. If your application is internet facing, this is a necessity, there will always be that user who will look through your code and see what he can do maliciously or just for fun... or that guy on who wants to see what happens when he uses the debugger to create his own fake ajax calls with varying parameters.
Related
Wondering if someone can provide some direction.
I'm creating a Wordpress plugin that will be publicly available (free). The plugin is meant to allow bloggers to include a definition widget using bootstrap's data-toggle.
Since I don't want people stealing the content without attribution, the hyperlink will be pulled out from a private API.
Here's how I think this should flow, but I know that there are things that are inefficient:
Create a private API that houses all of the data. It might be as 3
branches of data:
id -- name -- definition
Have the plugin authenticate somehow with the server
Plugin creates a shortcode in Wordpress ie. [define="term"]anchor[/define]
When the shortcode is called, it pings the server and stores something locally in their sql db.
Additional Notes/Concerns
I understand that there is nothing such as being hack-free or altered free. But I want to get as close as possible.
A couple exploits I can see happening is if people change the cached info in the SQL DB. Is there a way to potentially kill the data-toggle content if this happens?
Also, I don't want people to be able to create their own calls to our API creating their own programs. That's not the intended use of this.
I apologize if my thoughts seem cluttered, but I can't seem to figure out a solid workflow in where I should get started with this.
If anyone can help bring clarity, I would greatly appreciate it.
I would be inclined to do the following:
Give every user a unique API token or other credentials
Link every token to a single IP address and reject any requests where the token doesn't match the IP address.
That way if you become aware of someone misusing the content you need only delete their token to prevent access, and can be reasonably sure that it's not being used on another server. Users can enter the API credentials in the plugin admin.
I think OAuth2 will probably be the way to go to authenticate clients - it's made for granting access to client applications and there are plenty of implementations available. You'd need to add the ability to verify that the user matches the IP, but that shouldn't be difficult.
I'm building a product that involves clients adding their FB app data into my product's dashboard.
In this case each client would have to go to developers.facebook.com/apps and create an app first.
I would want to have a button which says "Create App" in my website that when clicked, would create the app instantly for the client.
So is it possible to create a FB App from my website (with script, not manually) ??
Thanks in advance,
Altin.
It was possible couple of years ago, and now it's been removed.
First of all, I’d think about the question, “does every client really need their own app?”
Maybe it’d also be possible to have all of the stuff you’re planning to do (no details on that) under one app, and have it decide on what data to show based on the fact which client’s Facebook page it gets added to (if it’ll run as page tab app), or by some additional parameter passed to it when calling it. You could f.e. example automatically redirect to a sub-folder on your webspace based on this criteria, that displays individual pages for that client.
If that’s not an option, then yes, your clients will have to set up the basic app themselves (and therefor they’ll need a verified account) – and afterwards tell app id and secret to you. Many of the “advanced” app settings can then be set by you via script – look at what properties are marked as “(Editable via API)” here: https://developers.facebook.com/docs/reference/api/application/
(Although some of the basic settings, like category, description, logo etc. will still have to be set by your client themselves. But other, more “technical” stuff, that the client maybe doesn’t know about and doesn’t even want to be bothered with, like canvas/page tab URLs etc. can be set by you. I’d say that’s as good a compromise as you can get for such a scenario.)
I'm designing a simple web app for some elderly family members, 1 of whom has Alzheimer's. The end goal is to provide them each with a tablet (probably Android but irrelevant for this problem) that would be stripped down to ideally 1 bookmark on the home screen which opens my web app.
What I am looking for are ideas on how to identify the user without the conventional username/password methods. With their condition I know that remembering an username is going to be almost impossible, let alone a password. Ideally I would recognize the device and relate that to a specific user.
There will be other users on the app that access it through normal methods (username+password on PC/mobile/tablet), which I'm handling with Zend_Auth. It's just these 2 users who I am concerned about identifying.
Security isn't a huge concern as the data will not be sensitive in any way, but I still need to differentiate between users.
I am building this in php with Zend Framework. I'm really looking for more ideas than specific code, although anything based in php or javascript would be great. Any ideas or suggestions would be greatly appreciated. Thanks for your help
These advice are only valuable if security is not an issue :
On the bookmarks page, insert a token in the link, which you will use to authenticate the users.
if you can, check in the background for IP/user agent (if there is only one device that needs this simplified auth process, and assuming it's connection uses a fixed IP address)
And a simple idea if you have multiple users using the same device :
on your bookmark page, put a picture of each user
make it clickable, with the token discussed above in the href of the link.
That's simple to implement and easy to remember.
Hope that helps !
Suppose you're developing an independent, small sub-page for a big and well frequented web portal.
The sub-page shows entries from a public event calendar, and allows users to highlight those especially interesting to them. The highlighted events shall be highlighted (and maybe shown on a separate list) on each future visit of that user.
However, building a classical user registration system, or any other way of storing the user-highlighted event picks on the server, is not an option: The sub-module needs to be as self-contained and need as little maintenance as possible. It's one of the conditions of the project.
The only way to do this without building a login system of some sort (as far as I can see) is using cookies or some other local storage (Flash / HTML 5....) which has the obvious and big downside that it's tied to the computer, not the user.
Is there a way of storing a few kilobytes data on a per-person basis, but without having to utilize a login or openID, that I am overlooking? A reliable web service perhaps?
A "key/value" storage service, to which I pass a unique key (one that the user specified) and get the savedvalue in return, would be sufficient. There is no need for real security - the data in question is by no means confidential.
OpenID is not an option: It is not well known enough among the audience of the site.
Facebook would be an option, but I don't think they provide "storage" options like this.
As a workaround, I am contemplating offering the user their event picks as a text file download, that also can be uploaded and turned into cookies on another machine. But that is pretty complicated for the user, and thus not perfect.
We have a similar system on our site, where users can bookmark pages to a planner/wishlist function. The saved items are sent via a webservice and stored on our server, and there is a corresponding get webservice.
We have a 'lazy register' system. The first time a user saves an item, they are asked for their email (but no password, as nothing is confidential). This is hashed and saved locally using a cookie, then used to set/get the saved items. When the user uses a different computer they are again asked for their email.
The key is that a register and a login are the same operation, so there is no need for any password reminders or any reset functionality.
The Google Docs API provides programmatic access to Google Docs, where you can create and store documents and spreadsheets. Your application could have its own Google login, which it uses to create one or more documents per user. These documents could be used to store the user settings.
Provided you can get a unique ID from each user (an email address, or something more secure, perhaps), this should be fairly simple. You can even organize the files into folders—one per user.
Alternatively, you could combine Google Docs with the Google Spreadsheets API, where I have just noticed this rather handy feature:
Tables & Records
Interact with spreadsheets as if they're a database
using Tables and Records.
I developed a simple application on Facebook using PHP and I want to know how the people can add this application, and after adding the application a update is generated (e.g vipin join this application).
Thanks
Users don't add applications anymore. The closest they can get is bookmarking, which your application receives no notice of. The closest thing you can get to checking as a developer is checking is Users.isAppUser.
You also don't receive notice when a user grants/rejects permissions (which is generally a prerequisite to viewing your application).
Basically, you have to post notices and create feed entires in direct response to user action (unless they've granted you a perpetual session).
The old model of actually adding applications was all kinds of broken from a user experience point-of-view, so Facebook basically pulled the plug on it.
Yup, no more "Dude just added this app" messages in the newsfeed. However, Facebook will occasionally show "Dude uses the 'Thing' application" messages under the "highlights" section of a user's homepage. There's nothing you can do to encourage or discourage it -- it just happens.