I'm currently working on an app where users are able to log in and access their data from Firebase. The app used to just be a Flask app, so I used flask_login to help keep track of user sessions.
However, I'm now trying to use Vue for the front end (including the routing), so technically we will be running a Vue app as well as a Flask app where the Vue app will be making GET requests to the Flask app. I found a tutorial for authentication in Vue. I was wondering if I needed to both this as well as flask_login. If so, how would that look like?
Really late, but since this is not answered, I will give it a go:
I would recommend going with JSON web tokens (JWT). This post probably explains it better than I ever will.
The basic flow would be:
On the [flask] backend every API call that needs protection will have a decorator (similar to #login_required) that protects the resource from being accessed by users not authenticated. For a user to be authenticated they will need to fetch from "/login" and the server will respond with a token, store this in memory. This token will need to be sent with any subsequent API call. When the user logs out, simply nullify the token on the front end.
On my setup, I used flask-jwt-extended and on vue, simply make sure that you have a token stored, if not, render a login modal or popup or redirect to the login page.
Read the post I mentioned to understand the JWT refresh flow.
Related
With Firebase's Admin SDK, I want to allow a user to login (verify the user with my Firebase instance) without any JavaScript on the front end. Just an old fashioned POST, with the form data in the request body.
Then in node (server side) verify the email and password on the back-end, retrieve a token, update the user's session, pass back a cookie, etc. I've been digging around various examples and the Firebase Admin SDK docs but have not found an answer.
I can do it if I run the non-admin-SDK Firebase module, in node, but this seems like an odd approach to me, especially as I need the Admin SDK for some other things.
I could see why they want to force a "triangle" approach like say payment auths use.
Authorize with Firebase on the front end and pass a token to the back-end.
Not allowing the password to possibly be sent or stored on the node server unencrypted.
But I want to pass as little JS to the client as possible and I want my site (MPA) to be progressive (not need JS). It seems odd they would not address this in their docs. Other than in some explanation of how to write one's own validation or integrate with another.
If anyone can describe how this can be done or what the recommended approach is, I would be very happy.
Firebase's Admin SDKs are designed to be stateless, so don't have a concept of a current user. The recommended approach is what Firebase Authentication does, sign in on the client and pass an ID token with every request/connection to establish the identity of the user.
If you don't want to use Firebase's SDKs in your client-side application, you can call the REST API. I'm not sure if you can construct the right call with a FORM post though.
Also check:
Sign in with Firebase-Admin using node.js, the main answer is the recommend approach.
How to authenticate an user in firebase-admin in nodejs? shows how to sign in a user in Node.js with the regular/non-Admin SDK. This is probably closest to what you want to accomplish.
Use case
I am creating a paid blog website, where people can pay to bloggers to see their blogs.
Solution i Chosen
I have chosen NextJS to build static content(SSG). With fallback option, static content can also built after site is deployed.
Problem
Now, the problem is authentication. We can not authenticate any incoming request on server like SSR.
The only way to check authentication is present on client side. Use useEffect hook to check if the current user is authenticated or not.
But, the problem with this approach is that, any user can disable javaScript on client side to view the content.
Is there any way to authenticated SSG page request on server side.
I don't want to use SSR because increased cost.
You can you use a service called Auth0 to implement static site authentication. It is free up to several thousand requests per month and has React components you can use. Make sure to follow the tutorial for auth0-react and NOT nextjs-auth0 (this is for SSR).
Here is the link to Auth0: https://auth0.com/
You could return null if the user is authenticating on SSG. If you're not loading any content via an API, then the user would be able to see it in the code (but not many users would be doing this). There is the option of Vercel Edge Functions now if you haven't managed to fix this issue yet.
I am trying to authenticate a user inside a desktop application using the web api. I am not using a browser, I am using straight up GET and PUSH calls to the endpoints of the Spotify servers. Immediately I ran into some problems. It appears that upon the initial GET command to "accounts.spotify.com", the returned response includes HTML with a javascript function that runs and is responsible for dynamically generating HTML that you see on the initial login page. If you look at the Javascript function, it is clear that this is what is going on, however, you can also see this code is obfuscated and not meant to be used by us, the developers! (Link to Javascript code here for reference: Javascript function)
So my question is, while I can probably reverse engineer the code to get this working, would this be against the Spotify developer TOS?
Thanks!
Spotify's authentication happens through oauth, and a big part of user authentication as per the oauth rfc is where the user delegates permissions to your app to carry out API calls that affect their account, or return information about them. That's the web page you're seeing - it must be presented to your users so that they can delegate permissions so that Spotify can give your app an access token. It doesn't necessarily need to happen in a browser - it can happen in a web view inside your desktop application - but it does need to be loaded over https, and your application must not alter or reverse engineer the Spotify permissions delegations page.
As you correctly guessed, reverse engineering any Spotify APIs is against terms of service.
For more information on authorization on the Spotify platform, I'd recommend having a look at this guide.
Hope that helps! Please ping me if you have any more questions.
Hugh
Spotify Developer Support
I am creating the vuejs app on node js and want to call moqui as rest API. So I just wanted to know is there any mechanism which can be call from vuejs and it will authenticate user credentials by returning a token, so for the next time it will authorize user by token only.
Am I understanding you correctly in that you want a temporary api key to pass to other rest calls?
If so, have a look at the rest.xml screen in the runtime webroot folder. There are lots of examples there.
I am still a newcomer to both the Vue.js as well as the Flask framework. I have created a simple todo app that consumes JSON endpoints from Flask and uses Vue.js to display the UI.
My app has a TODO, PROJECT and USER model. I have successfully implemented a "normal login" through my own user model. The flow for this one:
The user fills in username and password.
POST request to Flask API that saves the user with a hashed password in the database.
The user can log in through an /auth endpoint and receives a JSON web token in return.
When the user logs out, the token is destroyed.
Now I want to implement a google sign in along with the existing user model. I could successfully create a call to the google API and have retrieved the user data from google in the vue.js client. But this is where I am stuck.
What should I save in my database now? I don't have a password for the user, but only a token to identify later when I have sent the data to the Flask server.
Should I save both Google Auth users and the normal users in the same database table? How can I differentiate between them when I retrieve their information to check if the user exists?
As I am very concerned about building safe applications in the future, I would like to really understand what the best practice in such a situation is.
Thanks for your help!
For anyone interested in this topic: I ended up saving all users in the same database table and created a boolean whether the user was logged in with a password/username or with an OAuth provider. If so, the provided token could be used to verify the user.