What i want :
I need to create a twitter application in which i will be providing user login, once user gets logged in, it should ask user to give permissions for Direct message and tweets, once user allows for it, i need that user's Consumer API keys Access-token and access token secret keys
What i did :
I have created an application for my Twitter account, I have generated
Consumer API keys Access-token and access token secret keys for
my application, now which way i should go?
I have seen couple of application which asks users to get logged in and their application generates access token n etc for logged in user, and stores to their DB, which can be used later on for sending and receiving DMs and tweets in customer support like applications.
I am looking to do it using java-script.
Your help would be appreciated.
Please let me know if you required further details.
I wrote a Javascript application that allows users to schedule tweets, retweets, and like tweets, and it uses technology you are asking about.
It does not generate Access Tokens & etc. for the user, because that's Twitter's job... But once the user collects those from Twitter and saves them in my application, you can set up tweets, and schedule when they should go out, and it will Tweet to your account for you using the Twitter API.
Here is my app, you can look through as an example, or even download yourself and run locally on your computer.
Here are the code files on GitHub
This is the live app! Try It!
Your apps needs a server, and if you run a Nodejs server, you can use this NPM package to make interacting with the Twitter API very very easily. IT supports, Tweets, Media Uploads, DMs, Streams, almost everything!
NPM Twit
If you want users to be able to login into your website/app using their Twitter account, you can use Passport.js to easily accomplish this. Search on YouTube, there are many many tutorials.
Passport + Twitter Auth Strategy
Good luck!
EDIT: To answers you're comments: Yes - you can get/send Tweets and DMs on behalf of another account. You MUST acquire the API KEY & SECRET and the ACCESS TOKEN & SECRET. The client MUST provide these to you. There is no other way to Tweet and DM for other accounts, aside from getting their password and logging directly into Twitter. Read Twitter Developer Docs.
Related
I am trying to integrate docusign with a React Native app I am building. My desired workflow is to have the user launch a remote signing envelope based on a template.
From the Node JS examples, eg009 seems to be the end result I am after. However, I am wanting to complete this with Axios/Fetch and Javascript.
My intended flow is to have the user enter in their name and email, and their spouses name and email. From there they press a submit button which sends the API call, and that is the extent of what the app does.
I am wanting the API call to then start the template flow, sending a document to sign via email to both that were entered into the app. I want the users to authorize themselves from the email, not the app. After both parties have signed, I want it sent to a third static email.
I do not want the users to have to authorize inside the app or be redirected anywhere. It seems a JWT would be best.
Does this seem possible? How would you suggest going about this?
I appreciate the help!
Looks like the JWT grant flow is the right fit for you here. Please see this article for more details: https://developers.docusign.com/platform/auth
There's no good solution for running DocuSign API calls from client as a result of CORS limitations.
Larry has some blog posts on this topic - https://www.docusign.com/blog/dsdev-building-single-page-applications-with-docusign-and-cors-part-2
You could use something like AWS lambda which is not a server per-se, but gives you server capabilities without the hassle of a server.
Check also the latest blog by Larry on this topic which superficially covers using React for single-page apps.
What is the difference between using Google OAuth and signing in users at the frontend of the application, and signing in users at the backend side of the application?
Example: Signing in users and getting the ID and a auth object in React or letting Node/Express handle everything, the prosess, redirecting and store it in a database.
Is there any advantages for one or the other methods, which are most common and are there any "rules"?
What is the difference between using Google OAuth and signing in users
at the frontend of the application, and signing in users at the
backend side of the application?
So to clarify to everyone reading this, signing in users at the backend side of the application is another way of saying OAuth for servers and signing in users at the frontend of the application is OAuth for JavaScript browser applications such as React.
Signing in users via OAuth for servers and browsers results in a 'token' that a server/browser can use to make requests on behalf of the user. We are asking the user to provide us access to their information via an outside service provider such as an email address, identification of some sort and it will be inside that token as well as some possible permissions that allow us to take actions on behalf of that user.
Is there any advantages for one or the other methods, which are most
common and are there any "rules"?
Server-side OAuth is usually used when we have an app that needs to access user data when they are not logged in. So if you are attempting to build an application that needs to access the users email every ten minutes and possibly delete emails on the users' behalf, you would want to be able to access their email account every 10 minutes regardless of whether they are logged into our application. So for this use case we want to make use of Oauth for server.
Otherwise, if we are not trying to do anything on behalf of the user except sign them into our app, then we can just go with OAuth for browser.
Those two things are very different. Without knowing the specifics of what you're trying to accomplish, you should know as a general rule that front-end-only authentication and authorization leaves you extremely vulnerable.
If someone knows JavaScript well, or is using editing plugins, or any of a million different things, they can bypass much front-end authorization. Or they could just watch to see what calls your app makes to the back end, then simulate those calls from something like Postman, bypassing your web front end entirely.
If you're not securing your backend, you're not secure. Typically systems do both.
It is just a different ways of registering users to our website.
Signing in users at the frontend using OAuth can be very handy as it enables our users to not go through our boring forms in our website. Using OAuth is just one click away from registering users in our website. Beneficial to both the clients and developer.We are provided with the general information about clients by the provider(google,facebook) just clicking on one button.
Signing in users at the backend side is the traditional way of registering our clients. Here we force our client to fill the forms in our website(which may be painfull if it is a long form) and all the filled data is stored in our database.
So they are both different ways to register clients to our websites. Both are used very often. It depends on usecase and needs. Oauth can be used if you want to attract more clients by registering them just by one click.
We have a web app that caters to a small set of users that are guaranteed to have an account on Office 365.
To save them from remembering one more password, and to use Microsoft's infrastructure for OAuth, we decided to allow them to login using their Outlook credentials.
It is a react app, we are using the msal library and we have successfully been able to receive the accessToken from Microsoft. (Thus, authenticating the user's identity.)
What I am not confused about now is what I should do with that token:
I need to have my own User database. What information should I store in it? Should I store the access_token as well?
How do I verify the user's identity on my backend server?
Basically, what is the ideal way of managing this kind of a scenario? Wherein a third party authenticator is used (and solely) used to confirm the identity of the user and get the name, profile image and other things only.
Any references to existing workflows or an explanation of the steps involved will be highly appreciated.
I need to authenticate users in browser (not mobile app) using AWS Cognito with username/pass, not FB/google IdProviders.
There are a lot of docs but they seem to be separate blocks which either incomplete, do not fit the requirements or do not fit each others :(
I created Cognito User Pool, then Identity pool and tied the userPool to the idPool, then I stuck. Do not know which library to use and how to use it.
The closest I find are:
https://aws.amazon.com/sdk-for-browser/ but my experience is not enough to convert their FB samples to not-using FB
https://github.com/aws/aws-amplify but using this lib I'll have to study React/Angular from the very beginning (I'm not a front-end developer, sorry) and I have no clue how to convert their npm-based samples to front-end javascript (npm is for NodeJS thus back-end, isn't it?).
All I need is plain html form with username/pass, send the request to Cognito and a way to check during the next page load whether the password was correct. If it matters I will use AWS Lambda as back-end for processing future tasks.
How can I do it? Is there a tutorial/doc for my case?
Thank you.
You can use AWS Cognito UserPools Hosted UI for your use case. The simplest form of authentication is using the Implicit Grant.
For more information about setting up Hosted UI refer Add an App to Enable the Hosted Web UI.. This will create a UserPool where users can register them self (If you plan to restrict this, you will need to either add users using the AWS Web Console, Cognito UserPools or using their SDK)
The steps are as follows.
Set up Cognito Hosted UI and register your application domain. This will create the login/registration pages for you where each of this will have a unique URL. What you have to do is, if the user is not authenticated (Let's discuss how to detect it later), you need to redirect the user to the Login page.
In the Login URL, you also need to specify the redirect back URL to the application so that after a successful login, Cognito will redirect back the user to the application providing the token in a query string.
You can then access the id_token from inside the application and use it for querying the backend.
Since the id_token is a JWT token you can verify it at your Backend using the public key available at the Cognito token endpoint.
To implement the JWT verification, you can also refer Cognito JWT Token validator NodeJS module.
Note: If you need to keep the user's logged in for a longer time period (Than 1 hr), you might need to use the Code Grant flow which will return a Refresh Token, which could be used to retrieve new id_tokens programmatically.
I want users to be able to register on my mobile (web based) app and login using their Facebook account. Is this possible using the JavaScript API?
The user can login using Facebook, and the userID and auth code of that user can be sent to my server to create the account, but I see a security flaw because then anyone could then log in as anyone by sending a userID and their own auth code. So can user accounts not be done with the JavaScript API and only with a server side API?
All Facebook requests are also signed with a secret key that belongs to the app you've registered to handle Facebook sign-ups on your website, so you can use that to verify it comes from Facebook and not someone else.
This is also outlined in the registration documentation
Strictly speaking, it is not possible for the Facebook SDKs to explicitly create a new user. However, when you implement a 'Login with Facebook' button (see here for JS and here for PHP), Facebook's OAuth dialog appears, which will prompt the user to log in (if they are not already) or to sign up with Facebook, thereby creating a new account, albeit not under your control.