Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am definitely going to use an authentication scheme (Devise) with 3 roles: user, admin & sponsor. The question is: should I implement authentication right away or wait until I have my other models/views in place first?
I think it is usefull to do it as first, so you can easely integrate them in other models, eg. log that a user does something, you will also be able to set weather a user should have access to a specific controller.
Unless, you have a good reason to not do it...
A rather unexpected question, but you can safely create your authentication routine right away. In any project i create, authentication is definitely one of the first things i code, most times using Sorcery instead of Devise.
IMO it doesn't really matter, but why not do it earlier than later? It's pre-built, allows early testing (and testing it often), and allows access control needs to evolve organically rather than waiting until they all pile up and you have to do it all at once.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm a bit new in rails development I'm modeling a website with few resources and so far so good. But here is my question:
I would like to allow the admin users to manage information show in most of the pages: Application name, telephone number, address, default email and this kind of things.
My current idea is make a model Property with name and value, but somehow I'm not convinced about this approach because I'll need to access the database to get this values for every request.
Thanks everyone for your time! :D
This seems like an OK approach. If you implement caching, it no longer will hit the db with every request, and honestly it probably isn't really that big of a deal even without the caching. Build it the way you need, and optimize afterward, if necessary.
With all this being said, it may be worth considering how much things like the phone number are going to change, and balance the cost of developing a dynamic solution against the time it would take to change once, 3 years from now (if the number ever does change), in a partial.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Sorry I am asking a question that has been asked before but in spite of reading all of them, I am still confused what to do. What exactly I have to do to implement the remember me feature in my website . Is calling the function "setcookie()" alone sufficient
If you are not using identity, then you may need to use cookies for that.
Keep a checkbox in login page for Remember me.
If the checkbox is checked, keep a cookie with some identifier which is in turn stored to the db.
Next time when anyone comes to the login page, check for this cookie identifer in the database and if it exists, login
automatically.
You can read more by doing a quick search on how to remember user using cookies.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
i just started coding iPhone apps on xcode and i was curious what is the best database to use? For example a database to store names emails etc, to make a sign up and login page.
Cheers
If you are talking about storing a database local to your device, coredata is the standard: https://developer.apple.com/library/mac/documentation/cocoa/conceptual/coredata/cdProgrammingGuide.html
Small amounts of data can be persisted using user defaults: https://developer.apple.com/library/ios/documentation/cocoa/reference/foundation/Classes/NSUserDefaults_Class/Reference/Reference.html
When you said the words "sign up and login page," I suppose you are talking about an online database.
Use Parse.com's BaaS (backend as a service). Its also super easy to implement. Here is a tutorial from them talking about how to make a sign in/sign up page.
Keep in mind, there are other Baas like Kinvey and StorageRoom which are also good as well.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm about to start building a Rails app that will eventually need to vary CRUD access by user (i.e. which pages do they see, which can they edit, etc).
Is there a best stage of the development cycle to incorporate this?
Part of me feels like it should be the very first thing, since almost every piece of the interface will in some way rely on checking the user's ID, and it will be an inherent part of the DB structure.
Another part feels that this would overcomplicate things to start out with, and that I should instead build the core parts of the app, then layer on the authentication/authorization later.
Are there any best practices around this sort of thing?
I would say that if your system will rely on some kind of authentication... Why wait?
Let's say that you start developing your application without the authentication layer but at the same time you know that at some point you will have to do it. That means that at some point you will develop the authentication layer, and most likely you will have to refactor what you have already built to adapt it to this new layer.
Also, to try to convince you a little bit more...When you say:
I should instead build the core parts of the app
You should consider that the authentication module might be a core part of the app too...
I prefer to do it early, but you really have roughly the same amount of work in front of you regardless of when you do it. It really a matter of opinion on when you prefer to do it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I was wondering what would be the best strategy to implement a badges system using asp.net mvc. The one that stackoverflow has is pretty interesting. What do you suggest?
I guess I need to clarify the question a bit. The problem would be the different criteria for earning every badges. How do make that logic extensible?
I'd do it purely in T-SQL, and set up a SQL job that runs periodically (Jeff did it using C#, and has a goofy system where it runs the process based on a page request).
Basicly, in your SQL Job, scan your member tables and calculate if anyone is qualified for a badge, if so, update the badge table(s).
Then in the front end, do a query to retrieve new badges for a member on each request.