So to be more specific, I am aware that an admin can see your browser history and stuff but can they see what you do in cmd and if you run cmd in general?
This question is rather vague. Do you have a specific question here? As a general rule, an administrator account exists to keep tabs on all actions performed on the host in question. The administrator would have access to whatever histories, file systems and commands you may have executed, added, deleted, etc.. In some cases, the logging level may be turned down, but I would never assume that your actions are invisible to an administrator account.
Related
I am not sure what code I need to share but it appears so that every-time I login, my firebase-functions session is maintained across that very tab, meaning if in my browser, I have logged in through one tab and open a new tab, i need to login again.
How can I make my firebase function session consistent i.e if open in one tab, I don't need to open across another tab.
This is thread which seemed relevant but it's been some time since OP posted it.
https://groups.google.com/forum/#!topic/firebase-talk/zkrJsCh0_sw
If I'm interpreting your question correctly, you
have a Firebase app that allows users to log in, and
you want a logged-in user to be able to open a new tab, and automatically be logged in there as well
You can do so by adding the following line to your front-end code, at a place where the Firebase SDK is initialized and available:
firebase.auth().setPersistence(firebase.auth.Auth.Persistence.LOCAL);
Instead of LOCAL at the end, the other two options are SESSION and NONE, each of which gets progressively more restrictive with how it allows users to remain logged in.
Note that LOCAL is the default, so you may wish to check whether this setting has already been changed elsewhere in your code.
Note also that the capital letters are correct.
You can read more about the options and see a more detailed example of how to implement this code at the official Firebase docs on persistence
If that's not what you're asking about, you may wish to consider clarifying your question to indicate how my assumption 1. or 2. are incorrect. Cheers!
Is there a way to protect the database from deletion? I mean it's very easy to click on the "x" next to the root node. This would destroy the whole app and cause an enourmous mess to deal with.
How to deal with this fragility?
EDIT:
Let's assume I have two firebase accounts: one for testing and one for the launched app. I regularly log in and out to use the other one. On the test account I delete whole nodes on a regular basis. An activated password protection would avoid a very expensive confusion of the two accounts.
If you give a user edit access to the Firebase Console of your project, the user is assumed to be an administrator of the database. This means they can perform any write operation to the database they want and are not tied to your security rules.
As a developer you probably often use this fact to make changes to your data structure while developing the app. For application administrators, you should probably create a custom administrative dashboard, where they can only perform the actions that your code allows.
There is no way to remove specific permissions, such as limiting the amount of data they can remove. It could be a useful feature request, so I suggest posting it here. But at the moment: if you don't trust users to be careful enough with your data, you should not give them access to the console.
As Travis said: setting up backups may be a good way to counter some of this anxiety.
I have been trying Phabricator platform for 2 days in that to use it in our team. Everything seem fairly great except one I don't know how to make it.
We want to add Code Review process to our work flow forcefully. So I config Differential. Then as a developer I can use Arcanist command line to send a diff to the web UI requiring someone else to review. Someone can also accept or deny it after reviewing. That is OK.
But me who should be waiting other's review acceptance before pushing my changes to the hosted repo, can do that with git push (not arc land or arc amend) without the acceptance. How can I prevent this?
In the upstream we have Herald check for the presence of a Differential Commit, which you can send an embarrassing email, trigger an Audit, or whatever. Because we're a small team, we trigger an Audit (presuming those instances are generally emergencies and can be reviewed later). If the repository is also hosted by Phabricator, you can set a Policy on the repository to who has access to push to it. We use this to gate contributors. Frequent contributors can land reviewed code freely. New contributors have to have code landed by the upstream manually.
As far as I know, you can't. A user either has push rights or he has none. One way would be to trust the committer not to push his things until the review was accepted. On the other hand you could drop the right to push and let the reviewer or an administrator land the patch.
One different (maybe little complicated) way might be to create some herald rules to prevent the push. But I am not sure if herald is flexible and powerful enough for that kind of job.
We have a client that is using Cart66 on their site. They want the option to accept checks and ship COD but only want admin users to have the ability to perform manual checkout, but in order to track a customers order history they want to place all orders through the site as the customer.
I guess my question boils down to this: is there a way to log in as an admin user then switch to a non-admin user yet keep admin privileges? They are wanting to switch to a regular user but keep the admin ability to manually check out.
They could switch the user to an admin, perform the transaction, then switch the user back to subscriber. Is there another way to keep admin privileges without these steps?
I hope that makes sense. If there is anyone out there that can point me in the right direction I would greatly appreciate it.
Thanks
Honestly, no. I've gotten around this by opening two different browsers. I.e. I'll create two users: the admin account (my normal account), and then an alternate (test) account that's set as a subscriber. I'll use my regular browser and log in as an administrator (my usual account), and then open an alternate browser, and log in as the test account. So I'll have 2 windows open, but each window has a different account open in it. Works just fine. I get to see everything that happens as and admin and a subscriber at the same time.
It would be cool if you could do something like you're describing though - but I can see why you can't - you're getting into user roles and capabilities that would make no sense if you could do what you're describing.
I suppose one possibility would be to use the current logged-in-user's ID, and write a function that would strip front-end capabilities (visually make them appear to be a logged-in subscriber), but it's a lot easier to just open two different browser windows.
I'd like to write a Qt application which main purpose is to warn the user that there are things to do before he should shut down the computer. I thought this is possible, since a lot of applications ask the user to save before quitting when the computer is about to be shut down. I also want the user to be able to interrupt the shut down process, like those applications allow the user to say "Cancel".
Is there a way to do this in Qt?
If not, how to do this at least in a gnome session? (Support for more desktop environments would be nice, but currently this application is for me and my friends only, and we all use gnome.)
I read about the signal QCoreApplication::aboutToQuit(), but the documentation says that it doesn't allow user interaction. My application doesn't use any widget (maybe only a system tray icon), so the QWidget::closeEvent isn't of any use either.
Will handling the appropriate posix signal help? But as far as I know, such a signal handler may only contain trivial statements and asking the user whether to really shut down isn't trivial.
Here are some details if it helps: When the user wants to shut down the computer, my application will check if the repository (he configured to watch) is "clean", i.e. there is nothing to commit. If there is something to be committed, the application should warn the user and let him choose to ignore the uncommitted files or to abort the shut down process (in order to commit the changes).
You should implement session handling. When the operating system shuts down, QApplication::commitData() is called and you can ask the session manager to allow user interaction:
Within this function, no user interaction is possible, unless you ask the manager for explicit permission.
There is also an example about exactly your use case here.