So I think this is very Valid Use case scenario.
So my application which is called ATP , is consist of multiple apps bind together .
My question is If I make the user login with one of these apps , Can I use that access token with the other apps as well.
So , I am believing if I use the same App Id and secret I think this should work . I have not tried anything yet so some help in this owuld be appreciated.
Thanks & regards
Yes you can. If you have right Application ID and Application Secret you can use this access_token wherever you want.
But I think you shouldn't, why? Because an user accepts one specific application to use his data, and he may not want to use it in other place.
But if we are talking only about coding, answer is simple: yes.
Related
PHP
My website is almost done, but i'm having some problems with security. Actually, i didn't have problems yet, but i need to prevent. For example, the login system, i'm using cookies/session for it. And as people answered here, cookies are easy to overcome, and it's vunerable.
What is the best way to do a login system, including the passwords and data security?
Also, i'm using cookies for write the names of the users on posts. For example.
(Pretending that the login was successful)
$Cookie = $_COOKIE['username'];
$Cookie = $FetchUserNameFromDatabase;
//Then, on posts to write the name of the user, from the cookie.
$DoPost = "INSERT INTO posts (username, message) VALUES ($Cookie, $AnyMessage)";
Is this the best way to write the users name on posts, from a cookie value (since after login, the name of the user is saved on a cookie)?
IF NOT, what is the best way to do it?
Thanks in advanced.
#EDIT
I forgot to ask. Also, what's the best way to prevent people do a lot of comments (mass-spam)? For example, i do a comment (or a vote, or whatever) and works fine. Then, i do another comment and it blocks me for some time and i can't comment again until this time expires. What's the best way to do it, or at least, what the major sites/forums uses to prevent it?
Thanks again.
Why don't you just use session ids? I'd implement a login using a https connection, then assign a sessionid, wich identifies the user against your db. For further reference you won't even need a secure connection anymore.
In case you want to identify a post just use somthing like "SELECT username FROM users WHERE sessid=" . session_id()
In point of view, you should only use cookie information when you perform an operation that DOES NOT change the state of your application; like displaying the User name in the top of a page.
However in every scenario that you application is changing its state like adding a new POST (in your example) you definetly must not trust the client cookies.
To answer "The best way to do it", it depends on what technologies your are relying on.
Edit:
To prevent mass spam you should use the cookie information and the request information the like IP address.
I was hoping to use the Graph API to retrieve a list of apps that the user currently has on their account - those that they are using or have used, and have not yet removed. This would be the same list as found by clicking App Centre and My Apps.
I'm not looking to get info about a specific application (yet; I don't know what app to look at, or how to get its ID).
This article: How to get the List of Facebook Applications for a user using Graph API
seemed to be the right answer (and the OP certainly liked it), but for me, while it works, it returns an empty array - but I have about 20 apps (mostly games) listed on my profile, half of which are in favourites. I don't need to know which are in favourites; I simply would like to know what apps a user is interested in.
I realise this is considered sensitive information, but since I cannot find what string to use for the api() method, I can't tell what permissions I'll need; I currently ask for read_stream but since the call itself succeeds, I assume I have sufficient privilege.
I see that you can list the app requests using /me/apprequests, which suggests you should be able to retrieve the list of apps (that's where the requests come from, usually, except invites to new games) - but I can't find anything that seems right.
Any ideas?
Thanks.
No, it is not possible to retrieve a full list of the applications that a user has TOS'ed.
As described in the comments to the OP, it is possible to deduce some of them from /[user]/scores assuming they have granted the user_games_activity permission.
What I am trying to do is get a list of permissions that an application will ask for when a user adds it. FQL says I need an app access token (which of course requires the application secret). I must be doing something wrong...I don't find it normal than only the developer of an application would be able to use the Graph to read the permissions the app requires. Has anyone seen something similar?
The permissions that you ask for depend on the script that is calling the login at that particular point, so it could be different in many places. One place in the app may only require basic permissions, while another place might require basic and email permissions. So you can't get a one-size-fits-all answer for an app because it isn't defined in one place, and it is not saved on the facebook server.
It might be that there is another solution to the reason why you want this information. What is it you are trying to achieve?
I've got a webservice which is executed through javascript (jquery) to retrieve data from the database. I would like to make sure that only my web pages can execute those web methods (ie I don't want people to execute those web methods directly - they could find out the url by looking at the source code of the javascript for example).
What I'm planning to do is add a 'Key' parameter to all the webmethods. The key will be stored in the web pages in a hidden field and the value will be set dynamically by the web server when the web page is requested. The key value will only be valid for, say, 5 minutes. This way, when a webmethod needs to be executed, javascript will pass the key to the webmethod and the webmethod will check that the key is valid before doing whatever it needs to do.
If someone wants to execute the webmethods directly, they won't have the key which will make them unable to execute them.
What's your views on this? Is there a better solution? Do you forsee any problems with my solution?
MORE INFO: for what I'm doing, the visitors are not logged in so I can't use a session. I understand that if someone really wants to break this, they can parse the html code and get the value of the hidden field but they would have to do this regularly as the key will change every x minutes... which is of course possible but hopefully will be a pain for them.
EDIT: what I'm doing is a web application (as opposed to a web site). The data is retrieved through web methods (+jquery). I would like to prevent anyone from building their own web application using my data (which they could if they can execute the web methods). Obviously it would be a risk for them as I could change the web methods at any time.
I will probably just go for the referrer option. It's not perfect but it's easy to implement. I don't want to spend too much time on this as some of you said if someone really wants to break it, they'll find a solution anyway.
Thanks.
Well, there's nothing technical wrong with it, but your assumption that "they won't have the key which will make them unable to execute them" is incorrect, and thus the security of the whole thing is flawed.
It's very trivial to retrieve the value of a hidden field and use it to execute the method.
I'll save you a lot of time and frustration: If the user's browser can execute the method, a determined user can. You're not going to be able to stop that.
With that said, any more information on why you're attempting to do this? What's the context? Perhaps there's something else that would accomplish your goal here that we could suggest if we knew more :)
EDIT: Not a whole lot more info there, but I'll run with it. Your solution isn't really going to increase the security at all and is going to create a headache for you in maintenance and bugs. It will also create a headache for your users in that they would then have an 'invisible' time limit in which to perform actions on pages. With what you've told us so far, I'd say you're better off just doing nothing.
What kind of methods are you trying to protect here? Why are you trying to protect them?
ND
MORE INFO: for what I'm doing, the visitors are not logged in so I can't use a session.
If you are sending a client a key that they will send back every time they want to use a service, you are in effect creating a session. The key you are passing back and forth is functionally no different than a cookie (expect that it will be passed back only on certain requests.) Might as well just save the trouble and set a temporary cookie that will expire in 5 minutes. Add a little server side check for expired cookies and you'll have probably the best you can get.
You may already have such a key, if you're using a language or framework that sets a session id. Send that with the Ajax call. (Note that such a session lasts a bit longer than five minutes, but note also it's what you're using to keep state for the users regular HTPP gets and posts.)
What's to stop someone requesting a webpage, parsing the results to pull out the key and then calling the webservice with that?
You could check the referrer header to check the call is coming from one of your pages, but that is also easy to spoof.
The only way I can see to solve this is to require authentication. If your webpages that call the webservice require the user to be logged in then you can check the that they're logged in when they call the webservice. This doesn't stop other pages from using your webservice, but it does let you track usage more and with some rate limiting you should be able to prevent abuse of your service.
If you really don't want to risk your webservice being abused then don't make it public. That's the only failsafe solution.
Let's say that you generate a key valid from 12.00 to 12.05. At 12.04 i open the page, read it with calm, and at 12.06 i trigger action which use your web service. I'll be blocked from doing so even i'm a legit visitor.
I would suggest to restrain access to web services by http referrer (allow only those from your domain and null referrers) and/or require user authentication for calling methods.
Why don't people use CFLOGIN? I remember having problem with it with CF7 some months ago, but I couldn't remember what was wrong with it.
I use cflogin all the time and it works great. It can be a little tricky to get working the way you like, but the benefits are huge. Being able to fine tune your application with user roles takes care of the bulk of my rights based customization. There used to be some issues with session management that made it difficult to work with. Turning on j2ee sessions seems to make most of those issues go away.
Some of the popular frameworks are not compatible with cflogin, so that might be one reason you don't see a lot of it. They tend to have their own approach to securing application features.
I think a lot of people get frustrated with it because it is a little quirky and they give up on it. Others have more complicated security needs that aren't addressed completely by cflogin, so they wind up writing their own system. Specifically, there isn't an easy way to deal with rights by content asset.
The only issue I've had is with roles in CF8. It's brilliantly implemented, and a little cruel that it doesn't work as it quite should. Maybe in CF9.
In any event, building your own roles based system (assign the user a session variable with a comma separated list of access levels that the system can check against) isn't too hard to do and I got over it.
The one nice thing about cfLogin that is probably still worth using is how it ties into the Server monitor to see how many people are logged in, etc.
The point above about using the jsession is true, it's worth doing in all cf apps. One of the best things I dragged myself through to get working how I wanted it.
CFLogin is not used for 3 reasons.
First, it's a little touchy, a little strange, and doesn't work how many would think. You put some code here, and if a user isn't logged in it runs it... that's just odd, you know? It didn't help that there were some bugs early on, either.
Second, while it has the basic required security features for a web application, it doesn't go any further. You can't really extend it easily. Who's to say that's how everybody wants it?
Third, and most realistically, it's because people have already solved that problem. The problem area of securing an application, authentication and authorization has been thought out in the community long enough and most people know how to just do it. CFLogin is reinventing the door. It is too little, too late.
Now, that's not to say that no one uses it. I personally have used it a few times with basic success, but no reason to ring a bell. For most of my applications, it makes more sense to not use CFLogin. The problem domains are this way or that, and CFLogin doesn't always solve it in the most intelligent way.
Do keep in mind that CFLOGIN has a catch with Basic HTTP Auth where it can continue to send its UserID and Password even after you have called CFLOGOUT.
I know this has driven some advanced users away from it.
Here is an excerpt from LiveDocs
Caution: If you use web server-based
authentication or any form
authentication that uses a Basic HTTP
Authorization header, the browser
continues to send the authentication
information to your application until
the user closes the browser, or in
some cases, all open browser windows.
As a result, after the user logs out
and your application uses the cflogout
tag, until the browser closes, the
cflogin structure in the cflogin tag
will contain the logged-out user's
UserID and password. If a user logs
out and does not close the browser,
another user might access pages with
the first user's login.
In my case (suppose for some other people too) the main reason is moving from other platform, say PHP. I mean that I've already got some knowledge and habits in ACL development and started using them in CF.
I know how to make it handy for user, flexible for developer and secure and don't really need to switch to cflogin.
Sometimes the same happens with other stuff, say in most cases I prefer to implement client-side validation using own JS instead of using cfform/cfinput.
Because it (still!) has serious bugs, like this one:
http://www.raymondcamden.com/index.cfm/2009/8/7/Watch-out-for-this-CFLOGIN-Bug