I learnt that using Customizable Authencation backends philosophy, one can create a website which accepts email addresses as usernames. But after building the corresponding logic and testing that my code is working fine, I found one issue with Django's own testcases. They were failing to follow the Customizable Authencation backend philosophy. Meaning, the testcases were actually having hardcoded values('username': 'testclient') for testing the "login" process. Why is that? Django always discourages Tight Coupling. But whats happening here?
I am not bashing Django by any means! I am a big fan and I will be, for years to come. Just want to know the reason behind this!
Update: As #dmishe pointed out those testcases should validate Django's own functionality. I understood that. But how do I let those "failing testcase" errors NOT show up when I run my testcases or run the whole project test suite?
As dmishe points out, it is not a problem that the contrib.auth tests test the functionality that is built in to the contrib.auth app. It is a problem that those tests are run for user projects by default, and it is easy to break them via normal settings customization. This is a problem the Django developers are aware of and working on possible solutions.
In the meantime, my solution is to define a simple bash script to test only the apps I want to. So instead of "./manage.py test" I run a script that does "./manage.py test app1 app2 app3...". Not perfect, but it's far from the worst of my problems :-)
Update: This commit might interest you.
I don't see a problem here, django.contrib.auth.tests should test auth app and nothing more. Thus, it should test built-in backend which is username/password combination.
Related
Beginners find many quick construct templates and tips to get started with basic flask-python applications but it is very dry for complete ones. A complete app needs minimum login functionality and password management. Max Halford boilerplate is high quality (https://github.com/MaxHalford/flask-boilerplate/blob/master/README.md) Other fine references are welcome.
I have tried PythonAnywhere, Lynda and most of stackoverflow. All fine with basic starters, but not minimum login and password management examples.
Password change and forgot password are minimum elements of password management.
Any other fine references out there?
your first go-to should probably always be the documentation.
Flask-Login , Flask-Security.
the best overall comprehensive example of what i'm assuming you're looking for in this case can be found here.
the tutorial covers everything from building your flask app from scratch through deployment. enjoy!
I've been researching how to test my Ability and Users for a small test rails wiki i'm building and i'm having difficulty wrapping my brain around how to test either or both ?.
I think i'd like to sign_in a user as admin/editor etc. and test that user behaves like it should. I'd like to also test that Pages are displaying the correct information for an authenticated user.
This is more then one problem and i'm looking for some basic nudging less then an answer :).
I use Rspec, Cancancan, Rails 4 and devise for authentication.
I've read up on a few ways none of which worked for me:
Cancan example
Another ex i tried for cancan
Devise and rails 4 I'm using route authentication for devise.
Devise and sign_in
In any case here are my files. I'll just link to my git repo
my abilities.rb
pages.rb
users.rb
pages_controller.rb
I have factories as well but what's the trick to doing the following
Signing in users: The examples suggest using the devise test helpers then creating a signed_in user stub. I haven't quite succeeded at this yet :( so a nudge in the right direction
Devise and abilities: My understanding is I need to use the cancan/matchers then make some factories for admin/editor or any views and then do my usual tests once i've logged in a user and instantiated abilities. also failed at all the examples I tried.
Finally testing the controller for pages: I required again logging in the user with the correct ability and then testing each action for each users to see if i received the correct records back?
Maybe i'm not separating out the roles enough or i'm missing some important steps from what I could read but even a small nudge on any of these would be much appreciated.
You may have seen this, but this CanCan page https://github.com/ryanb/cancan/wiki/Testing-Abilities describes some basic high-level methodology behind testing the ability class. TL;DR Focus heavily on testing the Ability class itself and keep the controller tests light.
I've been working on. A web project for few months now.And it's a simple website with usual django models views urls and templates,with simple Ajax using jquery for the templates.
Now thinking of having a possibility of making an application soon. I am thinking of using Tastypie to make a RESTful api for my website. So the idea is to
Use Tastypie to make a RESTful api.
Using backbone.js to make my website a single page application
Using plist and json for my android and ios applications.
My concern starts here, with this new course of action, would. I have to make most of my website again? And if that is the case should I stop working on what I've already made and then start from scratch following the above guidelines? Again, in context to tastypie and backbone.js, what would happen to my already written views and template logic?
I've been reasearching over this topic alot and cannot find a definitive answer. So thought of asking all of you who are already experienced or have gone through the same transition.
I have almost no exposure to RESTful APIs. But I am getting inclined towards a RESTful approach as it would make app development easier.
PS. I would really appreciate if I don't get negative votes for it, but advice instead.
You could try it out side by side in the same site/project. Keep the existing django views. Add new tastypie ones under a different URL, for instance "/api/".
Likewise, a single page app? That is just one new template next to the existing ones. Keep it at "/single/" for the moment. And keep the existing pages.
The actual functionality will probably stay the same. Extract useful code as separate functions out of your existing views and call them from both tastypie and your original views. This will probably even make your existing code clearer and cleaner :-)
I'd say it's much of a philosophical question.
If the site is on a deadline or in production I would probably put it in git and give it two head branches:
production branch
refactor branch
The benefit then is that you can keep the old site up and add new features and merge this in your refactor branch.
Then again it much depends on the complexity and how the site acts today.
Doing the two branch system will give you the option to stop the refactor without losing your old version.
I'm creating a Django powered website that will have numerous applications (Blog, Shop, Portfolio, etc.) that will be edited by 5 or so people, and I have so-far been designing everything with the Django admin in mind.
I have come to realise that this is a very bad way of thinking -as really- the Django admin should really only be for top level administrators, and should be used for exactly that: administrating the website, not contributing to it.
I wrote out the feature-set and realised that the number of applications the entire website should have (sitemaps,mailers,contactforms,comments,tags etc.)is much much larger than the number of features the editor should have access to (CRUD actions for blog/about section etc).
Is it better practice to build a complex permission based Django admin, or build a second custom "editors" admin to run concurrently.
I think this is something that should be discussed in the documentation, as until I realised this, I had a lot of trouble understanding how to break the website down into applications, as I was designing everything with the admin in mind (and what actual user should see in the admin)
I'd argue that you should build a separate "diverse" admin app. Here are the pros and cons as I see them:
Pros:
No need to tamper with Admin or use hacks to get specific features. I suspect you'll need several such given your requirements.
De coupling from Admin. While Admin is very useful it is a bad idea to tightly couple your app with it. All the more so if you are tweaking it. Your would have to watch out for any changes in Admin that would break your app.
Custom styling. I guess visual appeal may not be high on your list but it is far more easier to style your apps than the Admin app.
Separate the really super users from "line admins". Let only the power users see the real innards of your system.
Cons:
You'd be reinventing the wheel. Generic views make this easier but you'd still end up duplicating features or featurelets.
Testing. The Admin app is widely used and is fairly well tested. You can use it without writing any unit tests (for most part). If you build your own you'll have to build an extensive test suite around it.
It is a matter of opinion I think. But personally I prefer to create a separate admin and link a user group to that instead of using the main admin for both.
That way you can easily see how everything looks for the other users when there's a problem. It all depends on your situation though, so YMMV
http://github.com/uswaretech/Django-Socialauth/tree/master/socialauth/
I'm a bit confused on how I should use this. Of course, I read the notes at the bottom but I'm a Django novice so I'll need a little hand holding.
The structure of this looks like a project structure since it contains a urls.py but I'm also aware that applications can also have that. It also has a manage.py which leads me to believe it's a project ( plus the subdirectories ).
So should I just be integrating portions of this into my existing project? This isn't an application, right?
The README also mentions grabbing API Keys. So if I want a standard interface where you click on a google/yahoo logo and it forwards itself via Javascript to the authentication page where you login if you already aren't logged in, kicks you back to your own page, would I need API keys?
Any other special tips are appreciated.
[We wrote this]
There are quite a few forks, which are ahead of us so you might want to use that.
If you just want openid, you dont need API Keys
If you want twitter/FB you definately need keys.
urls.py and manage.py are too show a demo app.
socialauth is the django app, which you can pull out.
I would use the fork from agiliq (same guys).
If you look at the commits in agiliq and uswaretech, you will see that the agiliq fork has more recent commits.
https://github.com/agiliq/Django-Socialauth/commits/master
https://github.com/uswaretech/Django-Socialauth/commits/master
And you could also use django-social-auth, which might seem to be another fork, but it's a completely different implementation.