TLDR; best solution for private instant messenger with laravel.
So I have a live real time chat working on my laravel site, However at the moment I don't have the ability to private message, its located on the home page and every time someone connects their socket.id changes The code I used and modified was from this tutorial. (I can copy paste it here if you wish I was not to sure about the rules regarding that)
http://itsolutionstuff.com/post/laravel-52-chat-message-module-using-socketio-redis-express-and-nodejs-from-from-scratchexample.html
I have no idea where to go about settings this up between 2 users as a private chat and just wondering if anyone else has ended up getting an instant messenger type system working with laravel and if so any info would be appreciated - it does not have to be socket but I was wondering is ajax a bad way of going about it.
I ended up creating each user who signs in a room of their own using a random token.
When someone requests to pm them it is announced and they have the open to start a chat (a new lobby).
It then combines both tokens using their user ids in which order to combine them as the lobby.
I have also save each thread in the db using this method.
When a token expires it updates the token in the DB also.
I am sure this is not secure, however it is not enterprise or even used publicy more so a test.
If anyone else has a more secure or better way let us know.
Related
I am migrating to Xero and want to set an invoicing process to run once a month at a specific time using a cron job, I can get the cron job to fire and I have set up a php page based on https://github.com/XeroAPI/xero-php-oauth2-app which I can run manually and it works perfectly.
I've also used https://github.com/XeroAPI/xoauth to retrieve the tokens and store them in the keychain, I can see that they are there.
I've got a bit lost where xoauth says "Piping the access_token, id_token and refresh_token to stdout, so you can use them in a script workflow"
I'm hoping someone has done something similar and can point me in the right direction or even better give me an example as I can't find one online.
I assume I am missing a link between the 2 examples which transfers the token values.
When the cron runs I get the following error
'Fatal error: Uncaught BadMethodCallException: Required parameter not passed: "refresh_token" in /Applications/MAMP/htdocs/vendor/league/oauth2-client/src/Tool/RequiredParameterTrait.php:35'
which is not really a surprise as I'm not giving it a refresh_token as far as I can see.
I am using localhost on a Mac as a development environment.
I have seen a number of questions related to this from more experienced developers but no answers.
Thanks Gordon
thanks for your question. We have gotten this one a lot so I used this as the base for a XeroAPI community-corner video that I will share back here soon that walks through getting access/refresh tokens from xoauth, making api calls, and refreshing to get a new token set.
Answer
What you want to do is after you generate the access token with the xoauth repo. In your PHP script - plug in the access_token & xero-tenant-id (as 2 headers in your api call).
Authorization: "Bearer " + access_token
xero-tenant-id: tenantId
Ensure the API call returns your data. Then create a function in your script that does the following before future API calls
Refreshes for a new token_set
Saves new token_set to a DB or static file
Use that token_set 'access_token' to make your Invoice API call
Repeat step (1-3) at least once every 60 days
NOTE: you will need some kind of persistence to store the continually
refreshed token_set.
Hope this clarifies it for you. I will post back the video for an in depth walkthrough asap.
OAuth2.0 Background:
Essentially our move to simplify and standardize our API authentication came with some challenges in how to setup longstanding API connections for use cases that didn’t need to onboard an increasing number of new users. For instance, a lot of small businesses and accounting firms setup custom processes to batch import/export invoices.
The use case often did not have the need for an application user interface, so standing one up just to get a valid access token was a lot of extra work if the integration only needed to connect to single ‘admin’ type user for a specific Xero Organisation.
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 have a client that wants to take orders via an online form, with the idea being that an order can be submitted and stored in a database via my application while simultaneously generating an invoice on submission in QuickBooks.
How do I do this in PHP when the person entering in the order is not the client but a client of the client? It seems like Quickbooks uses Oauth tokens and a javascript library to generate them to connect a company to an app, but I'm simply writing a backend for one company and want that backend to create invoices when saving an order. How do I think about this?
I'm not interested in anyone having to hit a button that says "connect to quickbooks" especially not the person filling the order because again, that person is a customer and doesn't need to know about the internals of the customer's invoicing system.
I just really want to use the Accounting API to generate invoices. Is there no way to simply link my backend to my one company directly in the Quickbooks SDK configuration and achieve this, or do they need to use a javascript library to get tokens. I'm unclear about what direction I should be going in and don't want to waste time with a client-side library if I don't need it to do backend logic.
Here's some example code that does exactly what you're looking for:
https://github.com/consolibyte/quickbooks-php
Along with a quick-start guide:
http://www.consolibyte.com/docs/index.php/PHP_DevKit_for_QuickBooks_-_Intuit_Partner_Platform_Quick-Start
Also see notes about your comments below -- you're on the right track, you're just misunderstanding how OAuth works:
It seems like Quickbooks uses Oauth tokens and a javascript library to generate them to connect a company to an app, but I'm simply writing a backend for one company and want that backend to create invoices when saving an order.
Correct, Intuit uses OAuth, and a little Javascript thing to kick off the OAuth process.
I'm not interested in anyone having to hit a button that says "connect to quickbooks"
Someone needs to hit this button... BUT only ONE PERSON needs to hit the button ONCE, EVER, and then NEVER again.
The owner of the company (e.g. your boss) needs to click the button ONCE, which gives the OAuth creds (and the realm ID) to you. Once your boss has done this ONCE, then you have the creds to use forever, for all of the actual customers.
Your customers (e.g. the people actually checking out/placing orders) DO NOT click any buttons, nor do they see or have any idea at all that you're even using QuickBooks.
just really want to use the Accounting API to generate invoices.
Cool, you can totally do that!
Is there no way to simply link my backend to my one company directly in > the Quickbooks SDK configuration and achieve this, or do they need to use a javascript library to get tokens.
Follow the quick-start above. It should take you about 15 minutes to get a working OAuth connection, and then you never need to use the client-side stuff ever again.
You only need to authenticate every 180 days btw.
If you use the reconnect script, you only need to authenticate ONCE, and can automatically renew the tokens every 180 days, no user-interaction required.
https://github.com/consolibyte/quickbooks-php/blob/master/docs/partner_platform/example_app_ipp_v3/reconnect.php
Well with the realm_id for example, I don't understand how that relates to ouath.
The realm ID is just a unique identifier for the particular QuickBooks Online company you're trying to connect to. Yes, you need to store it. If you use our libs, this is done for you automatically.
I guess I don't understand if I'm developing for one client why can't I just get their realm_id from them and then keep using it rather than making them do some form of authentication?
Again, they only have to authenticate ONCE. That's Intuit's way of giving you the realm ID and credentials you need to connect. Once you've done it ONCE, you never need to do it again. It takes all of about 30 seconds.
If they were to just give you OAuth creds without any authentication, it would be a gigantic security hole. If you read the Wikipedia article on OAuth it talks in depth about this, and the goals of OAuth.
Okay I think I get it, so they have to authenticate once every 180 days?
Once every 180 days, UNLESS you use a reconnect script, in which case they just authenticate once and then never ever have to worry about it again.
So I can store the token and the realm_id in a database before it expires and just use that?
Yes.
In this way my client can authenticate and then my scripts can generate invoices for them when their customers visit our website?
Yes!
I am new to backend coding but I am getting the hang of codeigniter. I have deployed the simple task board application hosted on github and everything is fine. As it stands this application uses sessions to create a single dashboard that can be shared by multiple users. I would like to be able to set this up so that a user could register and start their own dashboard. For simplicity it would be good if this new instance or session (not quite sure if I have the terminology right) could share the same database.
So my question is can someone tell me what I need to research in order to develop this? I dont think I have the right terminology to ask google or manuals for what I need.
I prefer you to use codeigniter session library and for dashboard, you may be stored much data in session, so use "Saving Session Data to a Database"
check this link : http://ellislab.com/codeigniter/user-guide/libraries/sessions.html
This could be me making extrapolations from the documentation (which given how it's organized, isn't too difficult to do) but did Facebook make some big changes to how application developers create and utilize test users?
To my recollection (and I last did this about a month ago), developers used to be able to go to a url from within a logged in account that would convert that user to a 'test user', who had no privileges in the public system but could serve as a test entity for publishing, getting permissions, etc. I had a test user setup via this method and had generated access tokens for him/her that were saved to the database.
Recently this all stopped working. My first instict was to print out the properties of the Facebook object I had created, and where once there had been the JSON decoded user data, there now was an exception from the CURL process that accessed the /me/ api endpoint.
Facebook GraphAPI – Uncaught EntCannotSeeExistenceException: The entity (class EntTestUser) backed by id 12345 cannot be seen by the current viewer 12345 (EntID: 12345)
Values obviously changed to protect the innocent. The userids were identical however, which made it strange that the user possessing ID 12345 for some reason had no rights to see 12345
I looked through the Facebook documentation and found their what seems to be their new logic for making the application itself create temporary test users and generate login URLs for them, something alot of people here are probably familiar with.
http://developers.facebook.com/blog/post/429
Has this system superceded the old one? It seems that acting on behalf of test user accounts generated via the old method is no longer permitted since they are not made "by" the application. I wrote some quick logic to test this new process with fixed access tokens and it worked - I should also mention that all the application logic functions as it originally did with no errors for real user accounts. Has anyone else experienced this with their Facebook api apps? Can we definitely say that these old access tokens/userids/accounts made via that old method are now effectively useless?
Thanks as ever.
http://developers.facebook.com/blog/post/475
I hate to break form and answer my own question, but from the comments enough people seem to be having this problem.
Digging through the developer updates today I finally found the above post (having already written workarounds, of course) Quoted:
We have removed the ability to turn
user accounts in test accounts as
mentioned here to prevent
unintentional conversions of real
accounts into test accounts. The
proper way to create test accounts is
by using the accounts connection of
App Graph Object.
This tiny notification was mixed in with the updates for March. Probably should RSS their developer blog so these things don't take me by suprise again! This particular update became effective March 4th. In any event, it's good to have a conclusive answer right from the source.