Is there a way in the Drupal interface to exclude a specific user from workflow status without having to eliminate his account and make a new one?
Looking over his account, he does not have any of the roles to receive status but he does.
Alternatively, I'd rather be able to somehow search for his actual email in the entire system and make sure he is not listed anywhere. Is that even possible in Drupal?
Thanks
I had to just remove his extra account. He had an older account as a admin buried deep in the users.
Related
The Conduit API in Phabricator does not support setting of authorPHID parameter while calling maniphest.createtask. I can imagine this is because of security or some logical reason.
But I am developping my own frontend for Maniphest where the users (logged through Phabricator, so they are phab users and have phid) will add and edit tasks. What I need is that if a user creates task, he is also the author of the task.
But the problem is, that I can't connect to Conduit as any other user than "apibot" because I don't have others certificates in my front-end to do it. But if I log in as "apibot", then "apibot" is set as an author of the task.
Three possible solutions came to my mind:
1. retrieve certificate directly from phab's database
2. keep a list of certificates in some file in my front-end and update it manually everytime somebody will register
I guess none of them are really smart...
The third solution would be nice, but I didn't find a way, how to do it:
3. log in as "apibot", get certificate of userXY and then log in as the userXY
What would you suggest?
This question is not related to ASP.NET specifically, but more web applications in general.
I am building a web application wherein I am registering a user. As of now I am taking in very basic credentials like First Name, Last Name, etc of the user. In this website I am giving some information for free for any user who has just registered so that the user finds my website authentic and that it is not a fake website. After that, to get more information, the user has to pay.
The information my site provides will get obsolete after sometime. So, when a new user registers, he/she will get the new information that gets updated; but the old users have to pay to get the same new information.
My problem here is once the information gets obsolete the same person can re-register with a different set of credentials and get the new information. I want to avoid this from happening.
So my question here is this: what information should I request from the user, or extract from the user, to check that the same user is not re-registering? Or any other way to make this possible.
I am thinking of getting the IP address of the machine from which the person is registering and use it to check. But the user can use a different machine to re-register.
I am completely lost here and not getting the solution. I even checked on the Internet but could not find an answer.
Please let me know if you need any further information from my side.
You will not find a technical way to prevent users from registering multiple times. They can simply use another device, IP, another email account and different credentials.
What you can do is asking them to send you hard to fake "offline" information, like a credit card number or a photo of the ID. Some users may still be able to register multiple times this way, but probably not indefinitly. You will however lose many possible clients this way who are unwilling to provide such information for a test account, so this is likely not the solution you want.
My advice would be one of the following two:
Limit the information/service you give out to free users, so that even if they register again they will gain something when they pay.
Try to bind them to their account in a way where they would lose something if they threw it away. This may for example be providing user rewards for activity (real or virtual) or increasing their experience based on their history. Take SO for example: If you registered again, you would lose all your reputation. The users will think twice if this is worth the new content.
After reading all of the above, i think a good solution could be to let the user identify himself through facebook or linkedin. Few people will have a second account.
I think you cannot put any users like that because every thing can be duplicate
There are some ways for which the user must have payment mode or identity details like passport or it is windows application you can have finger scanner it will be definitely Unique..
You can do this (with limitations) with the use of cookies. Setting a cookie on the users device will allow you to determine who the visitor is and that they have already registered.
The limitations are that cookies can be deleted or blocked and are only valid for that specific user agent - the user could use a different device or a different browser on the same device. A lot of people don't really know about cookies though and how to delete them.
By tying this technique with a requirement to provide a valid email address you can make it a hassle for somebody to register more than once as they will have to create a new email account and then delete their cookies.
Whether this will stop enough people depends on your site and your requirements - if you're giving money away then this technique is not nearly good enough. If you just want to discourage the practice of multiple accounts it may be enough.
Your only way out is to have SOMETHING the existing user gets as a "gift?" or added value to maintain just one account. If you can identify items of value to your subscribers and offer to "give" it to them provided their account "attains" one or more status, then you'll get some control. Take stackoverflow.com for example, I don't need a second account.
Identifying by facebook or linkedin is a good option, but if you are giving such services. which are very beneficial for the users, so they dont mind on creating multiple accounts on even facebook or linked in.
So what i think is to set some reward type stuff with each user, and increase the services as they get increment in rewards.once they are good in rewards and are capable to use multiple services, this increases the probability that they will not create another account.
So I'm building out an app with Meteor and noticed when I log in with Twitter and then Facebook, I create two separate user accounts. Is there any built in way to make sure these are merged? I'm not seeing any email address in the twitter based user account, so I can see it might be difficult to figure out which accounts to link.
Suggestions? Thanks!
I've been in a similar situation so here's a good starting point for you:
You might want to do the merge at the Accounts.onCreateUser event. Basically, what you would do at this time is to:
Do a mandatory protocol / routine to save the email in some profile field in any authentication method as much as possible, so that you are able to do the next step, which is..
Whenever another authentication method is used (to create the user), you can compare the existing database of users (now confident that an email field would be present at all times to check against), and do the merge whenever an exact email match happens.
It's a shame I do not have the code now because I tried this protocol once, but I quickly decided that I'll just stick with one authentication method for some reason. Maybe I'll update this answer when I can get around to try and code that again.. or maybe not.
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.
We are currently transitioning our website to Drupal 6.x from a non Drupal source. One of the first issues we need to deal with is that of authentication. We have a central database where we keep member information. We will create a module to authenticate against this database however a question of whether or not to create users in the drupal is needed.
I'm worried that if we do not add user to the user tables and have our module keep sync that with the other database, then we will not be able to take advantage of other modules that may use the user module
My colleague on the other hand believes that this is not an issue we can add all necessary attributes to the global $user at authentication with our module.
Is there a standard way of dealing with this problem?
Thanks!
David
Look at the LDAP_integration module, they do something similar. When logging in and a local user cannot be loaded, a user is searched for in another application and when user&pass are equal, the user is copied in the Drupal usertable.
If you want any Drupal functionality (read: core and modules) to be associated with that user account, then you will need to use that user table.
This is especially true for anything node-related, so if you want people to be able to create nodes with referenced data you will need it. uids are stored in the nodes table in order to show who authored the node. Storing a uid in the nodes table with a something that doesn't exist as a relational key to somewhere else will only return an empty object. For instance, if a person wants to see the author of X node they will get an empty user object. Keep it. There's no sense in working harder just to remove it. Besides, you can store as little or as much as you want in the user object for each account.
I'd also suggest looking at the LDAP module. I was able to use it as a jumping in point to interface with a custom WSAPI authentication method for an external database that we have at my company.
Do you need to have both sites running in parallel? If not, then you don't need to sync the user tables. A conversion will be enough then.