I have been setting up Apache Airflow over the past few days as a way to manage dependencies across our platform. In order to secure the web ui, I have implemented OAuth authentication.
Authentication works, it logs the user in appropriately and then creates a user record for them.
One thing I don't understand is the significance of the 'Superuser' privilege - does it actually do anything?
When a user logs in for the first time, their account is created. On first log in, the account does not have super user privilege. However they are able to go to 'Users' in the UI and then make themselves a 'Superuser'. That doesn't make sense to me, also having this privilege does not appear to grant any more access to elements of the UI than a standard user.
Is it suppose to work like this?
I use password authorization and in that case difference is that Admin drop-down menu contains only Variables for simple users, but the rest for superuser.
Related
I'm developing a web app backed by Firebase which allows access to its content to only users who have signed up (using firebase auth).
my goal now is to allow unauthenticated users to view the app content but limit their usage (say, unauthenticated users will be able to view x pages per day they will have to sign up to continue their activity on the app).
I was thinking to achieve this by making an anonymous user type and follow his activity with Firestore, but then the question asked is what prevents the user from login in with a new anonymous user over and over again.
another approach that I was looking at is to limit the user actions with a session cookie, but didn't find too much information on how it works with firebase and if it's even possible.
Any suggestions on which approach you would go with?
Implementing anonymous accounts sounds like a good solution to me. Since you'll have two types of users, you can very simply differentiate them, and allow your normal users to see all the content, while the anonymous users see only restricted content.
To achieve this, you have to check each time a users signs in, if it's an anonymous user or not. If it's anonymous then allow him only to load a fixed number of pages. This can be really simply done in your app's code.
I've solved the issue with my #1 approach -
I was thinking to achieve this by making an anonymous user type and
follow his activity with Firestore
I've overcome my concern
but then the question asked is what prevents the user from login in
with a new anonymous user over and over again
by going to firebase console -> Authentication then at a bottom of the page there's advanced settings dialog, where i was able to manage sign-up quota.
this way, a user with certain IP won't be able to recreate anonymous user over and over again on a short period of time and hence abuse my app.
I have a Flutter app where most of the users should never log in. I also use this same app for a small selection of users that I personally manage and would like to allow them to create a Firebase account, preferably just with by giving them a password to access the account creation page. Ideally I don't want just anyone to be able to create an account, only those who I have personally given access to. Is there a way I could password protect the account creation page so that only those with access to the password could create an account? Perhaps there is another way to do this? Ideally, I'm not looking to get into a situation where anyone can create an account and then downstream I have to authorize that account so that it has the correct access. I really just want only those with the access upstream to be able to create the account. Perhaps this is not logical but this seems to make more sense than letting accounts be created by anyone and then approved by me after the fact. So my question really is, how do I password protect a page in flutter? Or is this just a bad idea and should I work to manage things downstream? Or is there another solution I have yet to consider?
Have you considered using something like a dynamic link that navigates to the specified page in the app when clicked. firebase_dynamic_links might be of help. Only those who have the link will be able to access it and I presume that you could manage the link actions from the Firebase console.
You could also opt for simplicity and create a password field that pops up before your account creation page
I am developing an app for my college and there are different types of users called students ,teachers , hod's
etc. When they login, how do I know a teacher logged in, or a student logged in? Is there any function in firestore for role based signups and signins?
I was thinking that when a teacher signs up, I will add a tag end of her uid.username that if username is 'DANIEL' while signup, I will add a tea for teachers and stu for students at the end of the name what they provided.
So when they login i will get the uid and do the string manupulations and get the last three letters so that i can know who logged in so that i can show different UI to Different types of users
Is there any best way to do like this ?
while singning up user enters his username example:"daniel"
i will update that username in uid.username like this "daniel-stu"(if student signed up),"daniel-tea" if techer signsup.
Storing this information in the user's display name can work. You can read it back from there next time, and take action in your application's client-side code. But note that this means that any user can change their role, since they can also call the same code to update their profile. If that is not a concern for your app, then this approach sounds like it would work.
If malicious users should not be able to change their role, then you shouldn't set that role from the client-side application code. In that case, you can set the role from a server (or your development machine, or Cloud Functions) using the Admin SDK. Since the Admin SDK runs in a trusted environment, it has expanded privileges and can update the profile of any user. So the Admin SDK could update the display name of the user in the same way you have in mind.
But this still isn't secure, since you're still setting a property that anyone can modify for their own profile. Again... if that is no problem for your app that is fine, but if the use-case requires that you can rely on the property to be correct, we have to keep looking elsewhere.
The Admin SDK can set additional so-called claims on a user profile that client-side code can't modify. Such claims are for things that affect the permissions of the user, such if the user is an admin, or what role/group your users belong to. This sounds quite close to what you are describing, so can also be used. And this time, only your code that runs in a trusted environment will be able to do so.
Finally, you could store the additional information about a user in the database. It's quite common to have a collection (Users or Profiles) in the database, where you store a document for each user (with the document name being User.uid). You create the document when the user first signs in, and update whenever you need to. You can do this from the client-side code (if there is no need to control what gets written), or from code that runs in a trusted environment (such as your development machine, a server you control, or Cloud Functions) if you do need to keep control. A big advantage of this approach is that all users can potentially see the information in this collection, where the client-side Authentication SDK only allows a user to read their own user profile.
For more on this, see:
Adding new data to firebase users (in which I essentially list the same options with fewer words)
Add extra User Information with firebase (store the information in the realtime database)
Associate Firebase Users to Database Records (also using the realtime database for the additional information)
Cloud Firestore saving additional user data
this video explaining custom claims
and many more previous questions on this topic
I'm trying to come up with a way to secure a set of Admin CRM pages that control a Meteor application I'm working on. There's just one codebase, with the server, customer facing website and admin facing website in one project.
I need a login page which can verify one username and password pair, and a simple way to check the status of the user on both the client and server side. I also need a way of the admin's authorization timing out if it hasn't been used for x minutes.
I've looked at the meteor accounts package and it's just way too much fluff for what I need. This website will only ever have one admin user, so there will only be one set of admin username and password to store. I don't want it stored in the database, rather loaded with a settings file on the server on application start. It doesn't need roles, emails, password reset functionality.
Any recommendations for a package or approach I could use to implement this?
I know you said that the accounts:password package seemed a little "overkill", but in reality it really isn't. What you are gaining there is pluggable UI (via accounts-ui and other packages that build off it). The approach I have taken is this (which happens to work well even for apps that do support multiple users, since ultimately you still need to bootstrap your start users).
First, I use a combination of accounts:password and alanning:roles. If you absolutely don't need the roles portion, you could probably get away without it, but in all my personal cases I have found it useful to have multiple levels of ACLs for the various users. We could get into a whole philosophical discussion on using roles/groups to lock down individual features, but that's sort of off topic for this discussion.
Next you need to boot-strap the user(s). Somewhere in your /server folder you will do something like:
if (Meteor.users.find({}).count() == 0) {
// No users created...create default users
Accounts.createUser({
username: 'myuser',
email: 'myuser#mydomain.com',
password: 'myp4ssw0rd!',
profile: { profileProp: 'propVal` }
});
// Add new user to whatever roles needed
}
There are some more things I usually do here, like checking to see if my roles exist, and if not, create them before I try to handle the users, but the key here is to do that when the server starts up.
Once you have your user(s) and role(s) created, it's a matter of checking/verifying the user/roles in your app. For menu items you can show/hide stuff based on whether the user is logged in and/or has a certain role, and you should also verify in your application routes that require ACLs, like your admin route. In addition, use the user id in all your publications as well to limit the data your users can see. Don't rely solely on hiding a menu option...security through obscurity just doesn't work.
Why do I suggest doing it this way? First off, it's really not THAT much code. You could literally do this in probably 20 lines, max, and have a full authentication setup. And the benefit of those lines of code greatly outweigh the 30min tops it would take you, as you will now have "real" user authentication in your app and have the ability to do things like OAuth if you ever decide to in the future. Most importantly, you unlock pre-build UI plugins that you don't have to code, built-in and add-on methods to help check ACLs, the ability to lock down data by user, and you don't have to try to implement your own solution.
My app can handle Medics and Patients.
So far everyone can login and perform different tasks on the site.
We want to avoid forcing people that are Medics AND ALSO Patients to create a new User Login and password.
So a Medic which is also a Patient should keep his same login and password but we are thinking that as soon as the person with this dual privilege logs in they should PICK which role (and maybe store in a session variable) he wants to log in as.
Is this recommended or can you please provide me with an alternative?
Please help. thanks in advance
Your suggestion for roleselection after authentication IS a preferred way of working with your users. Your application can perform authorizations based on the role, rather than on the user. It is also important for the user to unmistakenly be aware of the role activated performing certain tasks.
One small suggestion I could give is to be able to switch this role dynamically, at any point in time in your application, without having to re-authenticate or get back to some kind of main page in your app. That fast role switch would really improve its usability. And always have the activated role display somewhere in the screen.
Do Medics have more privileges?
Somewhat like an "Editor" is also a "Registered User".
You wouldn't need an extra logon, you would just need to setup the hierarchy and what tasks/abilities a Medic has over a patient - if that's your scheme.
You should create another role. MedicAdmin for example.