Using the Google Provisioning API, under Managing Organization Units, it states that the creation of a user within an organization unit is a two step process. First I must create the user and then I must move them into an OU.
This creates a problem if I am migrating somebody from a legacy system. Creating their account causes our routing to immediately start sending emails to that account, overriding their legacy account. However, we will often create these accounts in advance and so have a specific OU for which routing is ignored.
Currently, we have to create the account with a different email address (e.g. append "-renamed" to the username), move the account in the non-routing OU, rename the account back again and finally remove the extraneous "-renamed" alias that is created during the rename. This seems pretty messy for what should be a simple operation.
Is there a simpler/better way of doing this?
Sadly you cannot create a user in a specific suborg right away. I take that you have some kind of callback after a new user is created wired up to the routing, you can either tell that service to ignore the next callback for that specific username before creating the user or have your default organization as the non-routed one.
I can also just recommend using SAML SSO, especially if the user is going to need any other account, syncing accounts correctly and handling exceptions in this context can be a pain.
Related
I need to build an application that will only serve people in my workplace. Currently, everyone has a specific company email, which has a unique domain and format.
I created a regular expression that only validates our company email addresses, and configured the application to require email confirmation. This seems like it should be sufficient, unless a malicious person:
Finds a flaw in my expression.
Finds a way around confirmation.
Somehow gets a company email address.
I feel like this isn't secure enough though. Maybe I need to take it one more step, with some kind of pre-approved email list or something?
I'm curious if anyone else has faced this problem. (Most likely.)
Ok, here is my solution:
This will enable a second level of security:
On the User model, create a boolean field called user_active.
Then, create an Admin page that will only allow your admins to check/uncheck accounts.
Then, you can call User.user_active? before logging your users in.
This makes it much harder for somebody who manages to sneak around your security to access your app.
This would be a pain with tons of users, but if you only have 200 or so, this will work.
I'm using SpecFlow whilst writing an asp.net mvc 3 website. The registration system in the site consists of two views.
the first view asks for basic information e.g eMail, password and location, whilst the second view asks the user for the type of account (developer or standard user) and then name, address etc.
In SpecFlow terms then I have one feature Registration and two succeeding senarios, registering as a developer and as a standard user.
if this was one view I could test this using something like:
given I am on the registration page
when I enter Data1
and I enter data2
and I click the next button
then the registration should be successfull
as I have two views is it best practice to chain several given, when, and, then statements or is there a better way of doing something like this?
Any help apreciated.
Sean
I would avoid mentioning the different pages within the feature file, and handle that at the step definition level instead, e.g.
Given I am registering
When I fill in my basic information
And I choose to register as a developer
Then I should be registered as a developer
Given I am registering
When I fill in my basic information
And I choose to register as a standard user
Then I should be registered as a standard user
I have a rails app that consists of lots of accounts.
Inside these accounts users can create tickets.
What is the best way to give each ticket a Id that is sequential inside their account?
Obviously managing the id's myself seems to be the initial answer, but this seems to be filled with all sort of edge cases that would cause issues (for instance, two tickets writing down to the DB at once...)
I think you'll end up managing them yourself - I've implemented something similar previously, account stored 'current_ticket_id' and then when a ticket (for example) get's created it is still stored with a global PK but then an observer assigns it a friendly_ticket_id and then increments to one on the account model for the next time round. You can use the friendly_ticket_id scoped to the account via your URLs to make sure you get the right ticket back.
I have been thinking for a good while about how to tackle the problem of implementing an ID based user system while using ASP.NET MVC. My goals, much like StackOverflow's system are as follows:
Allow the users to change their nicknames without the "avoid duplicate" restriction.
Allow the users to authenticate via OpenID (not with password for the time being).
I wanted to avoid as much rework as possible, so I at first thought of using the membership, role and (perhaps) profile providers, but I found they were username based.
I thought of adapting the hell out of the SqlMembershipProvider, by using the username field to store the IDs and throwing UnsupportedException on password based methods and the like, just so as to be able to use the other systems. But it feels unwieldy and kludgy (if possible to do at all).
On the other hand, maybe I should roll up my own user system, but I'm not sure if even if I can't use the providers, I can still use some of MVC's features (plug my code in with MVC somewhere, I can think of AuthorizeAttribute off the top my head).
So I was wondering if anyone had run into the same design problem, and what solutions they had come up with.
The more detail the better!
I had to set up a quick membership system for a client, they had some requirements that didn't allow me to use the built-in right off the bat nor the time to build what they wanted. I have plans to eventually roll-out a complete membership management system, but like you, I needed something now. I went with the following plan, which will, eventually, allow me to swap out the built-in providers for my own - time constraints and deadlines suck:
I have my own Personal User Table (PT) - MembershipId, UserName, Email, superflous profile info. This is what the app uses for any user information. It's a class, it can be cached, saved in the http context, cookie - however you want to handle your user info.
I then set up the SqlProfileProvider for authentication, authorization, and roles. I don't use the profile provider (even for trivial settings) because it's a pain in MVC. I made no changes to the built-in providers. This is what I'm using for authentication and authorization.
When creating a user, my code does the following:
Check PT for user name and email, per my rules
Create Guid - MembershipId
Create MembershipUser, the MembershipId is the username (the email is irrelevant and not used), and user password, question and answer, etc.
Create the user in PT with the profile values and use MembershipId as the PrimaryKey.
On login, I get the MembershipId from PT, validate against Membership with the MembershipId and the password and I'm done..
When deleting a user, I do the following:
Check PT for user, make sure I can/should delete
Get MemberShipId
Use a transaction
Delete from PT
User Membership.DeleteUser(MembershipId, true) - this ensures that the user is deleted from teh membership and other aspnet_ tables
commit
And it works as expected :)
A few things:
User.Identity.Name will be the MembershipId (Guid). This is used for SignIn and Role management. My PT is where the user's info (save the password) is saved. I can change user names, emails, etc with no impact on Membership or Roles because Membership is based on the PrimaryKey from PT.
The signin requires an extra DB hit because you need to query PT to get the MembershipId to validate against (you could cache).
The built-in auth system is really heavy - if you look at the sprocs you will see all the hoops it goes through to validate a user. I'd recommend eventually getting away from it. But in a tight spot, it does a good job - and if you don't have a milion users, I don;t think it'd be a problem.
I didn't consider OpenId and I'm not sure how you would integrate it, although I think you could probably do the same thing as above and instead of validating against actual credentials (after they come back validated form OpenId) just log in the user using the MembershipId (don;t validate against Membership).
For me, the main point behind this was that the app uses a custom user model, allowing for changes to user name, email, names, etc. Without impacting the auth and roles. When I am ready to change to the complete system, I can change it without worrying about the impact to the app.
Kenji,
I would recommend looking at some of the existing OpenID providers for ASP.NET. It should be fairly easy to make them work with MVC.
Erick
Forgo the use of SqlMembershipProvider. The only thing it would really offer you is an out of the box admin interface. The rest that it brings would be a nuisance.
Just use the sql membership provider and add a stored proc to change the username at the database level.
What would be the best way to go about giving users the ability to share a private link that enables anyone who clicks it to view a certain page/document/item that have privacy restrictions in place?
In my case:
A User creates events which are limited to certain groups of relationships in the database (namely: friends, friends of friends, etc.) I have a :before_filter in the event controller that checks the eligibility of the current logged in user to make sure that that user has permission to see the event. If they don't they get booted to the root page with an error message.
However, I want a special scenario to exist where a user can create an event with those same privacy settings and IN ADDITION, be able to share a special link with his or her friends via e-mail, facebook, etc. Those users do NOT need an account (but will need to make one in order to sign up for the event). This is important because there is also a :before_filter in the application_controller which makes sure a user is logged in.
I'm thinking there is something I could do with routing here... Right now I just have the simple /events/72 setup. Should each event have two different links: a normal one, and a "special code" version which enables them to bypass those two :before_filter?
What are people's thoughts?
I agree with David Lyod's answer (separating this concern in a different controller).
But for creating the hash I strongly recommend you salting the hash with some secret phrase.
require "digest"
Digest::SHA512.hexdigest("#{created_at}#{user_id}.mysupersonicsecretSALT")
Doing this it is not possible, without the knowlegde of the secret phrase, to calculate the hashes and test them against your system until it hits an existing one.
If you're handling sensitive data you should not be lazy.
Cheers,
Lukas
I would have a separate controller that uses a hash value to reference the event.
Something simple like the created_at + user_id hashed to create a unique reference.
You could also simply skip the check on a certain action but I would much prefer the first solution .