I have to create login signup form in flutter with following modes:
Login fields: Email/Password
Signup fields: Name/Email/Password
Forgot password: Email
Is it good to have all this in single file and logically rendering hiding fields with different modes. Let's say I am on login I have name/email I click on create account than mode changes to Register instead of redirecting to new page, and additional field >> Name field is visible.
So is it good to maintain all these login register and forgot password in single page and logically maintaining it?
This actually depends on your approach and your requirements. But most of the blogs authored by Flutter developers online, they prefer to have a separate login and register pages. Personally, I also prefer separate files for maintainability when your code gets bigger and more complex. You can try to check some samples online just like this one.
Related
In all of my Rails applications I have a User model with name, email and password attributes (among others).
This seems to be the standard approach when building Rails apps.
The more Rails apps I build, the more I begin to wonder why the User.name is even necessary.
Wouldn't it be easier to just omit the user name everywhere right from the start?
From a user perspective, the sign up process will become easier. Instead of filling in four fields (username, email, password, and password confirmation), the user will have to fill in only three.
According to some usability experts this might increase the number of sign ups.
In addition to that, users will also have to remember less data, i.e. only their email address (which most people have memorized anyway).
So what might be negative implications of this approach?
I couldn't think of any so far.
You might need to make emails from your app personalized, maybe with greetings such as `Dear <%= username %>.
This doesn't mean you have to put name as one of the sign-up fields. You can put in the update form only, when the user edits their profile. Then you can make the edit_user_registration_path the after_sign_up_path_for devise.
I don't think using username is "standart" approach with rails apps. In fact, devise's vanilla approach is using only email on models.
However, being able to accept username or email has many other advantages. You may have other scenarios where users do not register at all. I mean, perhaps you are also creating accounts for users without any registration and you don't know their emails, if so using email will not be an option.
In some applications, we use more then 3 authentication strategies. Some users do not have a username or email at all..
In short, i think it really depends on your scenarios. But i am sure that using both email and username is not a rails convention.
If the main goal is a frictionless signup process then an OAUTH strategy would be the best way to go (4 fields of info down to two clicks), however you may want to collect the user info at a later time for a more personalized feel depending on what info you can capture from the callback.
I have gone a good distance in spring-security-core-2.0-RC5 (SSC) with Grails 2.5, but still a lot to cover. I am wondering how to achieve two tasks. So far and after integrating SSC in my project, I built a dispatcher that takes care of routing users to different landing pages according to their roles. This link shows how I do it. What I am wondering how others are doing is these two tasks:
How to customize the landing page. For example, instead of the typical "Please Login", I need to say "Please login using your provided username and password" plus an image or something. This means I have to override (or overwrite) the existing login page. What is the best way to do this?
The more important. When a user is logged in, I route them to different pages based on their roles, or even log them out if their account is !enabled. However, what I can't do is be in control when the user has no credentials at all. What I would like to do is instead of displaying the typical "Sorry, we were not able to find a user with that username and password.", I would like to intercept the behaviour and perform some actions before redirecting users to the logout/login page (actions like a web service request for example). How can I achieve this please - to be able to make certain tasks on behalf of non-authorized users?
For Task1 (custom login page) you Just have to place a auth.gsp page in 'app/views/login/auth.gsp'
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
How do miscellaneous account management pages fit into a RESTful design in Rails 3?
For example, a user registers (create action) and is then forwarded to a registration success page (? action) where they are asked to now verify their email address via a url with a token (emailed to them).
When they click the link in the email, technically they are "updating" their account as part of the verification process right? So I'm thinking that would somehow map to the "update" action but the update action is expecting a PUT request. Is that correct? How do you make that work via the email?
I'm also wondering how forgot password, reset password, etc also fit into a RESTful design? Just trying to wrap my head around this.
Just because you have a result design, doesn't mean you HAVE to restrict yourself to only CRUD verbs that map 1:1 to Get/Post/Put/Delete. That said, if you want to get really RESTful, you can start to think of some of these things in terms of being their own resources. For example user verification:
User signs up, and gets sent a verification email, you already have that all squared away RESTfully it looks like
Verification url looks like: http://app.com/user_verifications/new?token=foobar (GET)
They follow the url and maybe are presented with a "Hello Dan, welcome back! Click here to verify your account" at that point you submit a form to http://app.com/user_verifications to trigger the create action there. Now on the backend, you can perform whatever actions you want, updating the user, setting them to active, or actually creating a "UserVerification" model.
Not a perfect example, but the idea is that the RESTful interface you are providing has an additional resource, in this case "user_verifications" and a user is acting upon it via HTTP methods in order to achieve the user's goals. You can apply similar logic to reset/forgot password either with a "UserSession" type resource or even as specific as a specific "ForgotPassword" resource.
Success page is just create.html.erb file. Usually you are redirecting from create action, but here you can just render success template.
Verifying. If you want to stay REST you should add one more step: GET verify, where is the form with your token present, which will lead to PUT update action. User recieves a link to this page.
But I prefer to use simple GET request here, which will update information without any additional clicks.
The same way you work with restoring passwords and other functionality. You add a page to with form that gets email, then you send a letter with link to a page with form filled with tokens and so on.
I have just set up a new ASP.NET MVC website and I would like to change it to force the user to authenticate their email address by clicking a validation link in an email. I googled the answer with as many search terms as I could think of, but I guess I never hit the correct one.
I started playing with the membership objects to see what I could come up and I did see you can toggle IsApproved, and so I set the default to false. I registered a new user after that and no email came through (as I had expected), but also it logged me in anyway for the current session. Thats beside the point however.
Is there a built in mechanism for sending out a validation email or is that something I need to implement?
There's nothing built-in to achieve this. You'll have to implement the email sending and validation process yourself, unfortunately.
You're on the right lines, though. Once a user is registered on your site, you'll have to set their IsApproved property to false, create a random "activation code" and store this (usually in a manually added field on the aspnet_Membership table or as part of the ASP.NET Profile if you're using Membership Profiles), send off the email with a URL that contains the user's "activation code". Once the user receives this email and visits the URL, you grab their "activation code" from the URL, look up the account from the ASP.NET membership system and set their IsApproved property back to true.
For detailed information on how you can achieve this, take a look at:
Examining ASP.NET's Membership, Roles, and Profile - Part 11
This is Part 11 of a 16 part series on ASP.NET's Membership, Roles and Profile providers, and not only shows how they are used with the built-in functionality offered, but also shows how to implement some commonly seen functionality that isn't provided "out-of-the-box" with the ASP.NET systems. (Incidentally, the whole series is well worth reading!)
Although this article was written well before the advent of ASP.NET MVC, the basic mechanism for implementing a "verify-by-email" system is the same and is easily converted to be more ASP.NET MVC-friendly.
Like you observed, there is support for handling certain types of behaviors (like approval of an account, blocking, etc). Those are just extensibility points that have some sort of default behavior (like blocking an account after x amount of unsuccessful logins). However a mechanism for account validation using email links is not available out of the box. You'll have to implement it.