It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I am looking to update a facebook company page directly using cron and php.
Can anyone shed some light on the simplest current correct method of generating a page access token then extending that so that I may use that in my php script that I will run by cron?
I just want to write two simple php scripts, one that generates this extended page token by me opening that page within a browser monthly, and the other which would be executed by cron using that page token for automatic authentication independent of a users browser (I want my server to authenticate by itself) to post a simple text message to a company page that I am an admin of.
I am just looking to send short messages at particular times to the company page direct from the server without a person having to be involved.
Thanks
First of all, as you need to post to your company's Page, then you would require Page Access Token and coincidentally it never expires onece generated.
First you will have to implement login feature of Facebook along with extended permission manage_pages permission. The easiest and fastest way to do the same would be to create an App and then using Graph Explorer with the app selected, generate access token with the manage_pages permission. If you want to implement the same you might want to look at this example.
Edit: When using Graph Explorer you would be required to navigate to /me/accounts end point, there you would find the required access token for the page in question along with other pages you might administer.
After you have obtained the Page Access Token, you may then use the same to perform the posting of update using the PHP SDK's api method after you have set the access token of your Page in the SDK with setAccessToken(). Or you may just perform a HTTP POST with your message to your page at the endpoint
https://graph.facebook.com/pageID/feed?access_token=Your_page_access_token
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 11 months ago.
Improve this question
I've been searching how to make a public http request secure and all the answers are to use a token like JWT.
But from what I understand, the reason for using this token. Isn't this to prevent someone from trying to modify someone else's data other than your own?
Then user can still manipulate his own data using his own tokens. Because when you first connect to the app, you will get a token from the server.
That person can modify his or her data at any time. Wouldn't he be able to modify the game points he has at any time? (I actually saw an answer in another answer (which said to make that http call only available once after the game is over))
but if he knows the jwt token and http request url then he still can modify right??
Are JWT tokens used in the worst case to keep someone else's data from being touched?
The JWT token is just used identify the user making API request and checking whether the user is authorized to make that request. When you decode a JWT (Firebase Auth's JWT for this example), you can read user's UID and custom claims, etc.
Passing user ID directly in API requests is not a good idea because they are usually public (e.g. your Stackoverflow ID is 18516895) and easy to guess. So I can just try passing some random numbers/string and might be able to make requests on behalf of someone else. So JWTs are mostly used for Authorization and Information Exchange.
Also checkout: Introduction to JSON Web Tokens
But suddenly I want to raise my stack overflow score. Then just checking the token is not enough for server I guess. right? How do you prevent in this case?
Allowing users to update their score doesn't seem to be a good idea. Instead the score should be done totally on back-end and can be triggered by any action such as user winning the game.
Take Stackoverflow for example, only the person who has asked the question can mark any of the answers as accepted. This is authorization. No one else is allowed to do so. After an answer is accepted, the system updated answerer's score (reputation), so there is no API request that is made from client side to increase score.
The flow could be like:
Questioner accepts an answer
Verify JWT, marked as accepted if owner of question
Increase score (reputation) of answerer
Adding to another case of single player game Tetris where the user directly needs to update server for a win and earn points as discussed in comments, it might be best to send every move to server and run all game win logic on backend instead of checking for win on client and letting users hit a /win API over and over again. If the game is completed, then credit points to user if won.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 11 months ago.
Improve this question
I've been searching how to make a public http request secure and all the answers are to use a token like JWT.
But from what I understand, the reason for using this token. Isn't this to prevent someone from trying to modify someone else's data other than your own?
Then user can still manipulate his own data using his own tokens. Because when you first connect to the app, you will get a token from the server.
That person can modify his or her data at any time. Wouldn't he be able to modify the game points he has at any time? (I actually saw an answer in another answer (which said to make that http call only available once after the game is over))
but if he knows the jwt token and http request url then he still can modify right??
Are JWT tokens used in the worst case to keep someone else's data from being touched?
The JWT token is just used identify the user making API request and checking whether the user is authorized to make that request. When you decode a JWT (Firebase Auth's JWT for this example), you can read user's UID and custom claims, etc.
Passing user ID directly in API requests is not a good idea because they are usually public (e.g. your Stackoverflow ID is 18516895) and easy to guess. So I can just try passing some random numbers/string and might be able to make requests on behalf of someone else. So JWTs are mostly used for Authorization and Information Exchange.
Also checkout: Introduction to JSON Web Tokens
But suddenly I want to raise my stack overflow score. Then just checking the token is not enough for server I guess. right? How do you prevent in this case?
Allowing users to update their score doesn't seem to be a good idea. Instead the score should be done totally on back-end and can be triggered by any action such as user winning the game.
Take Stackoverflow for example, only the person who has asked the question can mark any of the answers as accepted. This is authorization. No one else is allowed to do so. After an answer is accepted, the system updated answerer's score (reputation), so there is no API request that is made from client side to increase score.
The flow could be like:
Questioner accepts an answer
Verify JWT, marked as accepted if owner of question
Increase score (reputation) of answerer
Adding to another case of single player game Tetris where the user directly needs to update server for a win and earn points as discussed in comments, it might be best to send every move to server and run all game win logic on backend instead of checking for win on client and letting users hit a /win API over and over again. If the game is completed, then credit points to user if won.
I have a webpage which has a form which allows users to add comments to the page to give feedback.
https://express-chat-comment-ap.herokuapp.com/feedback
You'll notice a user can delete comments, not only their own comments, but all of them.
So my question is, how would you limit those privileges to only that current user?
There is a major piece to all of this which is the web page is being integrated to a website which has a user login/user account already.
Also do I have to do any research regarding what back end their using now? Or can I keep this all encapsulated with Express/Node?
What packages should I use?
Where do I start?
Thanks in advance for your help!
You're putting the horse before the cart. This isn't really a "Node/Express" question; you're not going to solve it at the Javascript level.
Instead, your main question is actually "How do I do 'security'?"
More specifically: "How do I 'authenticate' users?" "How do I grant access?" "How do I prevent access?" And so on...
SUGGESTIONS:
User Authentication with the MEAN Stack
MySQL Authentication using Passport
OAuth 2 Single Sign on Authentication with Passport
Node.js: Token based authentication
Heroku: Managing Organization Users and Application Access
You must have an authenticated and logged in userID for each user that your server authenticates and understands. Each comment must be saved with the userID of the creator and you must be able to retrieve that from your data store.
Then, your server can check who the user is that is attempting an operation (probably from a logged in cookie that accompanies the request), what the operation that is being attempted and decide if that operation is allowed by that user. For example, if the user logged in is "Bob" and they try to delete a comment from "Alice", then the server will refuse to carry out that operation.
And, your UI in the web page can not offer operations that are not allowed (though the server must always check anyway). So, if you have a delete button in the comment, you would only show that button on comments that belong to the current user.
I'm in the process of using the facebook javascript sdk to provide user login functionality for a website.
What I'd like to do is simply take the logged in user's unique facebook id and then put/fetch data to/from a mysql database using the id to determine what data is available to said user.
However I don't really feel like this is very secure. Whilst I'm not storing anything sensitive like credit-card details etc, I'd obviously prefer it to be as secure as practically possible.
My fear is that with javascript being what is it, someone could fake the facebook id and just pull whatever they wanted.
I'm aware that the php sdk would provide a solid solution to this problem, but i like the javascript one mainly because it's easy to use and I have the basis of it set up (I admit it, I'm lazy).
So, my questions are:
Would this set up be as insecure as I feel it might be?
Is there anything I can do to improve the security of such a system, other than switching to the php sdk?
Thanks!
Facebook Ids are pretty hard to make up (at most a user will only know their own). Depending on what you store in the database (which will not be anything that the user cannot get on their own, unless you ask for extended permissions)
If you are worried about a user trying to get information from the database, add an access token or signed request to each row and us that and facebook id to get data. That will greatly increase security.
EDIT
There are few occasions where you get a signed request from a user:
* A signed_request is passed to Apps on Facebook.com when they are loaded into the Facebook environment
* A signed_request is passed to any app that has registered an Deauthorized Callback in the Developer App whenever a given user removes the app using the App Dashboard
* A signed_request is passed to apps that use the Registration Plugin whenever a user successfully registers with their app
Signed requests will contain a user id only if the use has accepted permissions though, and are not passed again if the user enters the application, and accepts permissions (meaning that the signed request would not contain the ID). Because of this saving an access token may be a better idea. Here is more on the signed request
Also the signed request is in the url (param = "signed_request"). I always parse it through c# but I am sure you can at least get one through javascript
It's pretty easy to spoof the origin using curl. I'd imagine Facebook has another mecanism in place to make this possible. If you inspect their code, it appears that they generate an iframe and pass requests through. If I had to guess, they have setup the requests to only be made from the Facebook domain, and ensure that the iframe can only be embedded in a page that has a white listed domain.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Recently I installed a certificate on the website I'm working on. I've made as much of the site as possible work with HTTP, but after you log in, it has to remain in HTTPS to prevent session hi-jacking, doesn't it?
Unfortunately, this causes some problems with Google Maps; I get warnings in IE saying "this page contains insecure content". I don't think we can afford Google Maps Premier right now to get their secure service.
It's sort of an auction site so it's fairly important that people don't get charged for things they didn't purchase because some hacker got into their account. All payments are done through PayPal though, so I'm not saving any sort of credit card info, but I am keeping personal contact information. Fraudulent charges could be reversed fairly easily if it ever came to that.
What do you guys suggest I do? Should I take the bulk of the site off HTTPS and just secure certain pages like where ever you enter your password, and that's it? That's what our competition seems to do.
Here's the issue, and why banks are still horribly vulnerable: their landing page is HTTP, so it can be man-in-the-middled. Then they have a link to the login, and the login page is HTTPS.
So if you go directly to the login page, you can't be Man-in-the-Middled. But if you go to the homepage/landing page, since I control that, I'm going to rewrite the login page link to be HTTP. Then I'll do a SSL handshake with the login page, and send you (the user) the insecure version. So now you're (the user) doing all your sensitive transactions - and the server thinks it's HTTPS - and I'm in the middle doing shenanigans.
This is a very hard problem to solve completely because it goes all the way down to the DNS level on the server-side, and all the way down to default actions in browsers on the client-side.
As a content provider, you could try putting in javascript to check that the secure areas of your site are being accessed securely (and hope that I, as a cracker, don't remove that js before forwarding it). You can also include your happy "Please make sure this site is accessed via https" banners.
As a user, NoScript has an option to make sure sites are in HTTPS.
There's a new technology (I believe it's a marker on DNS entries maybe?) not supported by all clients/servers that lets a server opt in and say it is only accessible via HTTPS and to die a fiery death if it's being MITM-ed. I can't for the life of me recall or able to find it on google though...
I would take the bulk of the site off HTTPS with some exceptions of course:
Any checkout or account editing screens.
Any screens that would display "sensitive" information.
To deal with the session hijacking issue, I would add another layer of authentication where you prompt them for their username and password again at checkout or whenever they try to view/update account information - basicly whenever you make a transition from http to https.
Yes, I would just use SSL to secure important elements such as input fields, passwords, etc. I believe that's what most sites do, including online banking sites.