"arc land" Applying with wrong user - phabricator

Strangely, I can 'arc list' and it's okay, all my work shows up and it seems to be me.
When I 'arc land', it shows up in the commit as being applied by 'admin'
I might have generated the wrong certificate when setting it up, but re-doing it didn't work. Besides, shouldn't arc list fail?
I tried disabling the admin account, and it still applied the diff as admin. My commits appear with a dot next to them because they were applied by a disabled account.
one is set up with mymail#example.com, the other mymail+phabricator#example.com. I would try manually editing the email address to something totally different, but Phabricator doesn't seem to have the option.
Does anyone have any ideas what I could try?

Phabricator links commits based on the email address, username, and real name, roughly in order. My guess is that your local Git is configured to commit as Some User <mymail#example.com>, so when the commit is parsed by Phabricator it looks for the user with that address and finds admin. Note that the author, committer and pusher of a commit can all be different (at least, in Git).
The easiest fixes are probably:
Delete the admin account completely (you can do this from the "People" application); or
log in as the admin account and change its email address in Settings.

Related

How to get rid of "Send email as you" permission in Appmaker

I have an appmaker app that used to send emails. However, my users objected to the permissions required for this feature, so I removed it. However, the "Send email as you" permission is still being requested and I can't seem to get rid of it.
I did the following:
deleted (not just commented out) all references to MailApp I was able to find via the search bar
exported my code and searched for Mail just in case I missed anything above
removed mailto: links, in desperation
pubished to a new deployment to verify the permissions required
I can see in the deployment that "https://www.googleapis.com/auth/script.send_mail" is being requested, which is undesirable. However, I can't edit it, and I can't see why it's being requested.
No matter what I do, I keep seeing "Send email as you" being requested. Am I missing something?
I never solved this problem, but I worked around it by running as developer instead of as user. While doing so, I noticed that I had an old trigger installed. It's possible/likely that old trigger was an email trigger, so perhaps the trigger was what caused the email permission. I'll never know for sure since the trigger was deleted.

How can you hide something from registered users but display it to anonymous users?

This is for Plone 4. It is quite a general problem. I have a form (ploneformgen) that I want anonymous users to see and fill in, but I want to hide it from registered users (i.e., users who have logged in). Similarly, I have a "log in" link in the navigation menu. Obviously, anonymous users should see that, but logged-in users shouldn't have to see it. I've tried many options which I won't detail here (workflows, scripts that change local permission settings, etc.) since none of them have worked. There must be a standard way of doing this, but I can't work out what it is.
Any ideas?
Untested, but it might work: Products.AutoRole can assign groups and roles to visitors based on their IP, without creating user accounts for them. It also has a switch to only give automatic roles/groups to anonymous users. A rule 255.255.255.255/0 should match all IPs, so all anonymous users get a group, and you can make the form private and visible to that group.
(Note that AutoRole is not IPv6-ready, though, and has caveats regarding user inheritance, particularly: it will de facto disable the admin account, so you should not activate it in your Plone instance, but in the Zope server acl_users, if at all possible.)
Another untested idea.
There's a not a very know product and I never used it in a production environment (but in my tests it works perfectly): collective.subtractiveworkflow (https://pypi.python.org/pypi/collective.subtractiveworkflow) and the use of workflow chain.
In practice you can design a second workflow where View permission will be subtracted from Member roles.
To be honest I'm not 100% sure of how this can work with Anonymous, just because normally you can't define permission for Anon users but not given to other roles. This can be the same in that situation.

drupal password reset not functioning AND email not sending for reset

I am not a drupal guy, and would hate to have to jump in and step through a login to figure out the password reset, but I CANNOT SEEM TO RESET ADMIN PASSWORD. I have searched on this. I thought this good link would be helpful:
http://knackforge.com/blog/sivaji/different-ways-reset-drupal-admin-password
so I tried the query suggested:
UPDATE users SET name='admin', pass='$S$Drl0vgZ9yuU9uc4JyaTMHxMPriC7q/PsOUOx52fCrVQSTpI/Tu4x' WHERE uid = 1
where that specific hash is supposed to represent the password 'drupal' - well, it doesn't work.
Furthermore, though I have changed the user.email field to my email, when I try and get a reset link, nothing arrives - and I've tried several emails.
I'm thinking maybe I have an older version? How may I determine this? I'm at the point where I'm ready to do a complete new drupal install, just to snip out the working portion of the login. It shouldn't have to be that difficult! I appreciate your help. Thanks
There are two main ways to do this.
You can execute drush uli, this will generate a one time login link. By default it provides one-time login link for administrator.
If you execute "drush uli some-username", this will generate one time login link for that user.
OR
excecute "drush help user-password" (Re)Set the password for the user account with the specified name.
Examples: drush user-password someuser --password="correct horse battery" Set the password for the username someuser. #see xkcd.com/936
Arguments: someuser The name of the account to modify.
Options: --password= The new password for the account. Required.
Aliases: upwd
-- To do this, you need to ssh into the root directory of you drupal installation.

How can I get rid of spam users

The company I work for have a small Plone blog. But we have a problem with spam accounts. We use captcha on the site and Plone sends a mail to the users that they must confirm before they can edit the user profile. Still about 600 spam users are created every day. In the Plone user profile they paste all kinds of commercial links.
We are located in Denmark and the blog is in danish, therefore I have made a script to delete all users with a non danish mail adress. But even though most of the real users have a danish mail account I probably still deletes some real users when running the script.
The spam users register from a vide range of ip-adresses, so blocking ip's is not an option.
Does anyone have ideas to what to do about this problem?
Disable Plone comments/public user creation and use a third party commenting service such as Disqus.
They somehow trick recaptcha (if you find out, please let me know :)
But how do they do the email validation? They don't have to. Plone join_form has a hidden field for password which is filled by this bot and Plone saves it as the real password (check the REQUEST object comming from this bot)
So the bot doesn't need to check email for password. That's how they get in and activate those accounts. So fix the hidden password field from join_form.
Then, remove all users that have links in their profile description (as a real user you don't do that, do you?). Also don't let the users to input HTML within their profile description.

Membership plugin : Can someone sign up using a fake email address?

I'm building a Membership site using wordpress and Membership Plugin .
The site is still on my localhost. I did some trial sign ups and it worked perfectly well. But I noticed that, I can use even a fake email address such as xyz#gmail.com or something to sign up and create an account. So that's the problem. I don't know how this will work when I moved the site to my server.
But do you guys think this is a security hole ?
And what can I do for this as a solution ?
Here's what I suggest:
On the registration page, add a field where users need to enter a special code to complete registration and make the code as an image (or at least as something robots cannot process easy). This will prevent robots from constantly signing up to new accounts with bogus information.
Next, perform basic email validation to make sure the format is correct.
Next, strip the email address the user entered and verify the domain part is correct and if it is, have your server automatically send an email to the new account holder asking him/her to return to a special section of the site where he/she enters a special registration code assigned to him/her to complete registration.
Also, to save database space (I'm assuming registration info will be stored in one), ask users to complete registration within a limited time period or they will have to start over. If the time is up then relevant data from the database can be removed. I suggest setting the time period to at least one day.
If you are unable to do this, then you may need to find a better plugin that has the functionality I described.
And whatever you do, play with the website on localhost and make as few modifications on the live server as possible. This means make all changes at once on localhost if you can then upload everything at once to the live server.

Resources