Hiii Friends, I want to override a method like forgot password default to override forgot the password to reset the password through an email link.
But I don't have any idea.
can anyone help me to give me some suggestion or hint?
You may go to your App\Http\Controllers\Auth\ResetPasswordController and add your methods. You may also need to read and understand how the Reset password works by default in Laravel here: Illuminate\Foundation\Auth\ResetsPasswords and Illuminate\Foundation\Auth\RedirectsUsers.
You may also read the Laravel's Authentication Quickstart, https://laravel.com/docs/5.5/authentication#authentication-quickstart.
There are other methods you can do actually, like adding reset() method on your ResetPasswordController or adding an event listener (https://laravel.com/docs/5.5/authentication#events).
You need to extend the Illuminate\Auth\Passwords\PasswordBroker Class from Laravel’s Authentication module.
But Even If you Extend this Class in your Project, It won’t work because PasswordBroker Class is referred by PasswordBrokerManager which is registered in ServiceProvider. So there are a couple of steps involved.
Follow this guide for detailed steps
https://www.5balloons.info/extending-passwordbroker-class-laravel-5/
Related
I have built some RESTful api's with REstlet 2.3.4. I've been using HTTP_BASIC which let the browser prompt for credentials but it's time for a proper login form. I figure the easiest way to implement this is CookieAuthenticator. I can't find full working examples on github/google. I am sure i'm over looking them can someone provide a working example implementing CookieAuthenticator in Restlet?
I did get this to work after all. I have a longer answer here with some code examples. First, i was missing the fact that CookieAuthenticator is a filter and HAS the logic to handle login and logout. You need to create EMPTY ServerResources with a method annotated with #Post that has nothing in the body. Second, extend CookieAuthenticator and overwrite isLoggingIn(..) and isLoggingOut(..) with the code found in the link.
Cheers,
-ray
I have installed django_two_factor_auth successfully: token logins, backup tokens and SMS via Twilio all seem to work fine. My users will not tolerate having to enter their token for every login, though.
My needs are similar to those discussed in the following:
https://github.com/Bouke/django-two-factor-auth/issues/56
I wish to offer the user an option to defer OTP verification for 30 days after a successful verification.
To this end, I installed django_agent_trust. I patched AuthenticationTokenForm to add a BooleanField if django_agent_trust is installed:
(two_factor/forms.py, in AuthenticationTokenForm)
try:
from django_agent_trust import trust_agent
trust_this_agent = forms.BooleanField(label=_("Trust this browser for 30 days"),
required=False)
except:
pass
and I have been able to unconditionally set and reset the is_trusted flag by using django_agent_trust's django_agent_trust.trust_agent API.
The problem is figuring out where to capture the user's selected value of the BooleanField. I'm lost somewhere in the form wizard.
I would accept an answer questioning the wisdom of my overall approach if I think your argument makes sense. Is there something I'm missing here?
in the beginning
django_agent_trust seemed like a good shortcut for this use case. It already had secure cookie support, a feature of Django I'd never used before, plus all the convenience methods I thought I'd need.
I was able to get it working with a little extra work.
problem
The problem I ran into was that django_agent_trust validates the signed cookie only after the user is authenticated -- with an authenticated user from the request object. Since I was trying to minimize changes to django_two_factor_auth, I needed to decide whether or not to show the OTP form before authentication occurs.
solution
All the tools I needed were in django_agent_trust. I pulled the methods I needed out of its middleware and into a new utils.py, adding a 'user' argument to load_agent(). Then I was able to check the cookie against the validated-but-not-yet-logged-in user object from django_two_factor_auth's LoginView class.
Now django_two_factor_auth's LoginView can test for agent trust in has_token_step and has_backup_step, and everything works more or less as the author predicted 11 months ago...sigh.
I think adding this trust element might make sense as an enhancement to django_two_factor_auth. Juggling hacks to all these components seems like the wrong way to do it.
later
I took a cue from the django_otp project and added agent_trust as a "plugin" to two_factor. It seems usable and maybe a little easier to digest in this form. This worked for me, but I suspect there's a much better way to do it. Patches welcome.
Hoping for a simple function I can use to store emails securely and retrieve easily when required to send emails.
Kind of a general question, but here are a few solutions I'm familiar with:
use django-encrypted-fields, which has an EncryptedEmailField
you can override the save method for encrypting the email yourself, then override the post_init signal for decryption. See example here (which is based on this)
you can build your own encrypted email field, see django snippet here (uses pyCrypto)
you can use django-extension's EncryptedCharField
If none of the above seems good enough, try google-ing around by yourself. You're probably not the first to tackle this problem
good luck.
The goal
No log in screens!
A visitor to the site should be able to create a widget without logging in.
This widget is publically accessible and can be shared via a short URL.
To edit this widget, you need to know the longer, administration URL.
The show action should have a URL with a short token instead of an id:
widget_path(widget) # => /widget/abc123
The edit action should have a URL with a long token instead of an id:
widget_path(widget) # => /widget/abcdefghijklmnop123/edit
What I have so far:
Generating tokens
I'm using a before_create callback to generate two tokens, a token and an admin_token with SecureRandom.urlsafe_base64.
Then, to change the URL helpers from generating URLs with the id, I override the to_param method in the model to return the token:
def to_param
token
end
Now when I save a new record, a token gets generated and the url helpers return these:
widget_path(widget) # => /widget/abc123
edit_widget_path(widget) # => /widget/abc123/edit
The problem
I need the edit_widget_path helper to use the admin_token field.
I can't seem to find a way of doing this.
In an ideal solution, I would want the _url versions of these to also work and they should be available in the usual places (controllers and views).
The closest I have found is to create custom _path and _url methods in ApplicationController, but this doesn't seem right.
Open to suggestions for how to achieve this.
Is there a way to use Rails' existing mechanism for generating URL helpers?
I hope that makes sense, feel free to ask for clarification.
Thank you!
I don't know of any rails mechanism that could handle that except inheritance. You could implement a subclass and override the to_param method there. I don't think that this is worth doing so, since you just want to handle 1 route here. I think I would just create a helper method to handle that case.
Another hint here: You could use the same mechanism that GIT uses. Create a UUID (long version) and use the first X digits to make the public url, just the full UUID is secret. This works in GIT 99,9% of the time without collisions, so it should work for you as well.
I'm using this snippet, that allows users to only need to enter an email address to register for my app: http://djangosnippets.org/snippets/686/
Things are almost working perfectly. The problem is when a user has an email address that's above 30 characters. I get a "Ensure this value has at most 30 characters (it has 40)." error.
This is because the username is only supposed to be 30 characters. Is there a simple way to just tell Django that the username can be longer? It seems like there should be a fairly straightforward override for this.
This actually isn't simple at all. This requires subclassing the User model and using that everywhere. I've never had to do it, for this case, but it would likely cause significant issues with the Admin interface. You could also edit django's source to pull it off (ick).
Or even use this solution:
Can django's auth_user.username be varchar(75)? How could that be done?
It's quite ugly though.
You're probably better off writing an authentication backend to use the email field for authentication rather than using the username field. To populate the username (which is required) then you'd just generate some sort of random unique username maybe by hashing or using a UUID.
Hopefully this solution should help you : http://www.micahcarrick.com/django-email-authentication.html