I am in a bit of a dilemma about how best to handle the following situation. I have a long registration process on a site, where there are around 10 form sections to fill in. Some of these forms relate specifically to the user and their own personal data, while most of them relate to the user's pets - my current set up handles user specific forms in a User_Controller (e.g via methods like user/profile, user/household etc), and similarly the pet related forms are handled in a Pet_Controller (e.g pet/health). Whether or not all of these methods should be combined into a single Registration_Controller, I'm not sure - I'm open to any advice on that.
Anyway, my main issue is that I want to generate a progress bar which shows how far along in the registration process each user is. As the urls in each form section can potentially be mapping to different controllers, I'm trying to find a clean way to extract which stage a person is at in the overall process. I could just use the query string to pass a stage parameter with each request, e.g user/profile?stage=1. Another way to do it potentially is to use routing - e.g the urls for each section of the form could be set up to be registration/stage/1, registration/stage/2 - then i could just map these urls to the appropriate controller/method behind the scenes.
If this makes any sense at all, does anyone have any advice for me?
I think creating a SignupController is a fine idea. The initial user registration is a distinct process, and ought to be separate from general profile management tasks.
If you've been a good developer and keeping your controllers thin and your models fat, you ought to be able to avoid any code duplication. If you find yourself duplicating, it's probably a good idea to think about refactoring.
As a concrete example, consider your user's email address. Let's say you're pretty strict, and any time a user changes their email address, they have to do a little confirmation-email dance. During signup, you'll want the user to return to the signup process after they click their confirmation link. When an existing user is changing their email address, you'll want them to land somewhere else (like their profile). It's likely that you'll want different content in the body of the confirmation email is each case. Trying to make /user/profile handle both cases is going to start creating a bunch of complexity where the action needs to figure out context and behave accordingly.
The better solution is to decide that signup is it's own mode of interaction, distinct from general profile management. Therefore, it gets its own controller, which shares model and view resources with other controllers.
That's my take, anyway.
Related
I’ve read that you should not use GET requests if you are modifying the database. How would you record analytics about your website then?
For example, I want to record page views whenever someone visits a page. I would need to update views = views + 1 in the database. Is this OK, despite using a GET request, or is there another technique? Surely, not every request should be a POST request.
The general advice about how to use POST vs. GET shows up in RFC 1945 from 23 years ago:
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.
POST is designed to allow a uniform method to cover the following functions:
Annotation of existing resources;
Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
Providing a block of data, such as the result of submitting a form [3], to a data-handling process;
Extending a database through an append operation.
These guidelines remain in effect to this day, but they cover the primary purpose of the user's page request.
The act of incrementing a view counter is incidental to the primary purpose of the request, which is to view the page content. Indeed, the user is likely unaware that this database update is occurring.
(Of course, you must expect that you will receive duplicate requests as users move through browser history, caches are populated, or spiders crawl your pages. This wouldn't be the case if a POST request was made.)
It's ok.
When you make POST request, you actually wait for POST params to come and you build your database insert query based on parameters which you've got from browser.
On GET request you actually implement your own business logic, so user won't ever know what is going on the side.
And for the finish, actually sometimes you can do something, what's going against rules, rules are good, but we are able not to follow them, that's what makes us human, if we would strictly follow all the rules, it would be cumbersome.
I have a (hopefully) quick question regarding sessions. Whilst I have used sessions extensively, I have not used them in a situation whereby the values change depending on a users actions.
After logging in to my application, a user can select a company area, which has many levels of pages and folders. All of these pages will need this 'company_id'. At the moment I send the company_id via GET, but as I get deeper into the application this is becoming increasingly hard to maintain, with various other data being stored in the URL.
Therefore, when a user selects their company, I could set their company_id in $_SESSION array. However, when a user changes company, I would then need to change $_SESSION['company_id'] to the new value.
Is this a good use of sessions? I could potentially clean up my urls by using session data rather than always using GET, but I am unsure if this is a recommended way of using sessions.
Thanks in advance
This is a bad implementation of the HTTP design philosophy. All HTTP requests should be self contained, RESTful. All information needed to get a specific page should be present in the request itself (URL, headers and body), not dependent on hidden state.
Super trivial example: you can't copy a URL to someplace or someone else and have them see the same page. The content of the page is dependent on session state, which has been laboriously set through the visit history of several previous pages. To return to this same page, you need to retrace the same steps, recreating some hidden server-side state to arrive at the same page.
This gets even more complex and messier if you take into account that a visitor may want to open pages requiring different states in two or more simultaneous tabs/windows.
All this isn't to say that it can't work, only that it's hideously complex and will break the usual expected behaviour of browsers, unless you really bend over backwards to somehow prevent that.
If the many levels of pages and levels are per-company, you can put the company_id in a specific include file - this part of the site being dedicated to a given company.
However if they're shared by multiple companies, and this is probably what you want, this is potentially misleading, or even dangerous depending on the user actions, since the user may jump to a given page (link...) and access a page with unexpected data linked to a company which ID is provided by the session or cookie.
You could dynamically build the links on a page, based on IDs, to ensure consistency during the navigation from that page. Any direct "jump" to another part of the site will not carry the ID with it (and the page may offer to select a company).
Depending on your web server and if you have control over it you could build the URL having "company ID" as an element of the URL path, not the GET parameters
Eg
http://example.com/invoicing/company382/listprices.php
using a rewrite (web server configuration) to change the URL to be actually used to
http://example.com/invoicing/listprices.php?compid=company382
(URL not visible to the user) that informs of the company ID via the GET parameters.
I am developing an application in php codeigniter. Now I am worrried abt the permission.
I need page wise permission, page may be add records page, edit page, delete page and print report etc. There will be many users as well, and applicaiton will grow with passage of time.
If I implement ACL that will better for me or not
what can be ideal for me any suggestion.
First, let's clear up some terms: I personally use the security term for things like preventing SQL injection, XSS attacks, where we have to validate input, filter/sanitize values, take care of the dynamically generated SQL commands, take care of properly escaping output (for JSON or HTML text or HTML attributes), etc. This is not about what you are asking, if I understood well.
The access control or permissions system is where you give or deny access to a function for a user. It can be secure or not. I understand that to deny a user which does not have permission the access to a function may sound like "security", but I wouldn't use this specific word in this context, to avoid confusion.
Now, the answer:
I strongly recommend you create a few base controller classes to your needs. Read the following blog post carefully (it is short and useful): http://philsturgeon.co.uk/blog/2010/02/CodeIgniter-base-Classes-Keeping-it-DRY
A code to check if the user is properly authenticated (logged in) is essential. If the user is not logged in, redirect to home page or login page.
For fine-grained control, you could create your ACL in the database using the users table, plus an actions table, plus an acl table...
The users table would contain the users data (id, name, login, password, etc)
The actions table would contain the id field and at least one more field containing what suits best for your application: it can be only the controller class name (the first part of the URL, for example: "products"), granting access to the whole "products" controller or not. Or you may want to include both the controller class AND the method name (the first and second parts of the URL, for example: "products/add" and "products/delete"), and so on.
To decide about the actions table is the most decisive step. Think very well about it, balance your needs (your "true" needs)... I developed a system where each and every action has its entry. It is good, but it needs work to be maintained.
A very useful column for the actions table is a human-readable description of the action.
The acl then would be nothing more than a column for the user id and another column for the action id.
A "master" grant/deny access field in the users table is useful too, in case you want to temporarily deny access from a specific user, without having to delete all his permissions and maybe having to restore it later.
With the database tables and your "controller/method" or "actions" strategy well defined, you can easily code in your base controller class a function which checks if the user have permission to execute the requested action.
This is the basic. In my system, I have the users administration interface, where I can grant/deny the actions for each user (I use an ExtJS tree with checkboxes). One of these actions is the own user management. I have gone one step further, where the user who can access the user management may "delegate" (grant/deny) to other users only the actions he himself has access to.
The system has several modules, and functions. The interface does not show anything the user does not have access. So, I have users who can see only a single or a couple of modules, and they don't even imagine the existence of the other modules.
It requires more work to manage all this, but the result worths.
I also log each granted access, so it is possible to track who did what, and when. This log feature is very very easy to add, since you have this base controller "master function" allowing or disallowing the users to perform the actions.
I hope I have helped. I've just shared a bit of what worked (and works) for me...
How would a customer be able to login with both their primary email address they signed up with as well as a Secondary email address customer attribute field? (I’ve created a customer attribute text field secondary_email).
Assuming it has something to do with customerEntity and would be similair to what people have been doing to get usernames to work: http://www.magentocommerce.com/magento-connect/Sylvain_Raye/extension/7928/diglin_username
or
http://www.magentocommerce.com/boards/viewthread/195573/P15/
I just need for customers to have 1 single password, but be able to use an alternate email address specified within their account if they want.
Thank you!
Magento is no different from almost all other PHP-based frameworks in that it has a serial flow of execution. Thinking from a request flow standpoint, an entry point to suss out your requirement would be the class which handles the login form POST. You can see this in the rendered source in your browser: action="https://demo.magentocommerce.com/customer/account/loginPost/".
The above URI resolves to the method Mage_Customer_AccountController::loginPostAction(). In there one finds typical login logic for a login controller action: is user logged in? is the user posting in login data? is the the login data valid? and so forth. This quickly points to the customer session model, Mage_Customer_Model_Session, particularly to the authenticate() method. In this method is a call to Mage_Customer_Model_Customer->loadByEmail(), which gets us to Mage_Customer_Model_Entity_Model->loadByEmail()`.
At this point, we know that we can rewrite the resource model and change its loadByEmail() to handle lookup of a secondary email method (messy & obtrusive). We could also rewrite and change Mage_Customer_Model_Session->authenticate(), providing some pre-processing to first load the customer record by secondary email, then extract the main email and allow things to proceed as normal.
//rewritten authenticate method
public function authenticate($username,$password) {
$customer = Mage::getResourceModel('customer/customer_collection')
->addAttributeToFilter('secondary_email',$username)
->getFirstItem();
//check we found customer record by secondary email
if ($customer->getId()) {
parent::authenticate($login,$customer->getEmail());
}
else {
parent::authenticate($username,$password)
}
}
I've not really looked into the above snippet, nor would I vouch for its security, but hopefully this demonstrates the process by which one can answer these types of questions using awareness of the framework. This may not be a bad starting point; with something similar in the configured class rewrite plus a setup script to add the secondary_email attribute, this should be quick to implement.
A note worth mentioning:
It's also possible to accomplish this by observing the runtime-constructed controller_action_predispatch_customer_account_loginpost event (see Mage_Core_Controller_Varien_Action::preDispatch()). While it is generally advisable to use the event observe system to effect functional rewrites when possible, this would be quite unintuitive and the messiest option of all.
I need to build a registration system which requires the collection of large data (many fields) from the user registering which is then inserted into a couple of tables in a database.
I don't really want to display a very long form to the user for the purposes of better UX.
This system will not run online, it is just a web app to run on the desktop.
I need help, pointers, references, etc on how I can better organize the registration process to make it more user friendly.
This How to encourage a user to fill in long application forms? has been helpful so far
As long as you don't mind requiring your user has Javascript, I would use AJAX. Let's say that you have 50 fields that you can logically combine into 4 different sets - the first may be about the person asking for name, email, etc., while the next set asks for historical information or employment information - like on an application.
Make one form for each set, and then present a new user with the first. When he completes the first page, instead of a "Submit" or "Register" button, use an AJAX call and a "Next" button to get the info and switch to the next page of the form with the next set of fields. You could use the AJAX calls to hold the information in a temp table in your database, and then, once the entire process is complete, you can write it to your member/users table.
You could do like other surveys or checkouts do and add a "title" for each page of the form above the form fields so that as a user moves through registration, they can monitor their own progress.
I'd recommend checking out the Amazon checkout, or really any multi-page survey (you may even be able to set one up yourself on Survey Monkey) to see how a large number of form fields can be broken down logically in a user friendly way.
Hope it helps.
Check out this link: http://www.smashingmagazine.com/2011/05/05/innovative-techniques-to-simplify-signups-and-logins/
It's talking about login- and registration-forms and how to make them more user-friendly. A suggestion which is also included in this article is as follows:
At registration don't ask the user to many questions. Only the basic data like their name for example. Then ask him about more detailed data when the user logs in the first time. This way the registration won't take too long.
Maybe this helps you out :)