I want to make middleware for my app to do this logic for me:
Allow registered user access the panel for 60 days (based on created_at column of users table)
Then forbid user to access the panel unless admin gives the access to user (this access will be recognized by second table were user_id will be defined)
What do I need?
I don't need you to give me codes (unless you want to show sample) but the main thing that I'm asking here is your ideas and solutions.
What do you think of this logic? or if you have any better idea? etc.
is using middleware the good way to achieve this or not?
For my little idea I think you can use midleware and it's the best way until someone offers something that I didn't know (I don't know much). midleware retrieves the user who issued the request and first checks whether he is eligible for the trial period based on his registration date. if not, he checks in the second table if the admin has given him access.
I like the idea but I think you could solve your problem with a column on the users table named something like 'access' which would be a boolean value. This value would be true when users register and allow the user to view the panel if the column is true.
Then after 60 days has passed from the created_at column change the 'access' column to false. You could check the created_at column in a scheduled command or job that runs each night and will change the column too false for users that have passed the 60 days limit.
Then in an admin UI or admin command you could just simply change the 'access' column back to true for certain users.
Related
I'll try and cover most of the important details here...
I'm currently working on a booking system for a transport provider. I am using Laravel and originally started by having the Booking model attached to a User.
The client now however wants them to not have to login or register until the last step of the booking process. I have done carts etc in Session / Local Storage before but I thought before I start I would get some input from the friendly folks over at StackOverflow!
The most ideal way for me at this point would be to make the user_id on the Booking model nullable, but then when the visitor returns to the site how will I then know which booking is theirs?
I hope this makes sense & I hope someone out there has dealt with a similar problem to this one and can shed some light on the best strategy going forward!
I created something similar to what you say in a company that has been working for some time, I indicate how I proposed it, to see if it can help you achieve what you want to achieve in the most optimal way.
As you indicated, I created the reservations with the nullable user_id, as it usually happens in almost all reserve applications, they are not eternal, so I added a field (max_datetime) of maximum time that reservation would last and a field (token) with code only for the reservation, in addition to a field (ip) for the ip of the session. (In the application that I made, the reservation was maintained 12 hours maximum or until 11:59 pm on the same day, which may be less than 12 hours).
Then create a Task Scheduling for a custom Artisan Console. What it did was eliminate the reserves that fulfilled the condition to be eliminated.
When the reservation was completed it was associated with the user_id and the other fields with null (max_datetime, token, ip). Ah! Yes and a field (confirmed) to confirm with "true" that the reservation has been completed, by default to "false".
I used session to check the "ip" and the "token", and if not, I asked that if they had the token, to indicate it.
The system allowed you to obtain the "token" in case you did not want to continue at that moment, warning you of the time the reservation was kept.
I do not have access to the code since it was from a company and I only kept the idea. I hope it helps you. A cordial greeting.
I've created an iOS and android app that uses a database where users can login which in my case "User_active" gets changes to 1 and logged out gets changed to 0. The only problem I have is that I cannot check to see if the user has left the app, or if they have closed it, so what I want to do is create an event on phpmyadmin to change the "User_active" to 0 after 30min, but I can't seam to get things right. I'm using Awardspace as my host and I've only seen tutorials for localhost. Errors that I'm getting are that my user account does not have the write privileges to create the events and I cannot find any user tabs to change user privileges. If anyone can send me off in the right direction that would be great or even better a solution.
phpMyAdmin is a fantastic interactive tool, but it is not the tool for this.
In some ways, this is a fairly common problem. Typical web based applications don't know when a user has left, they only know when a user does something. One method is to do the following:
1 - Add a field to the user table (the same table that has the "user_active" field) to track the last activity by that user of any type. This should be a DATETIME or TIMESTAMP field and updated always with the current time.
2 - Add a cronjob to check any records in the user table to see if they are (a) still logged in (user_active=1) and the timestamp is more than 30 minutes old. If so, set user_active to 0 - essentially force a logout after 30 minutes. You may want to have an additional field to indicate it was a forced automatic logout rather than a user-initiated logout.
If your hosting service allows cronjobs, then run this periodically (perhaps every 5 minutes) and you are done. If your hosting service doesn't allow cronjobs then one option is to add a call to the "automatic user logout" function as part of every regular page. That won't work if you have thousands of active users as the overhead would be too much (and the delay on each page display). But if you have a small number of active users it will get the job done - I have done plenty of system housekeeping using that method.
I am trying to build an online attendance system where employees sign in and check in daily except for weekends and vacations.
so , my idea was to create a daily attendance record as a table in the database.
Attendance_date_daily date
Employee_ID number(auto generated)
Check_in_time time
Check_out_time time
Attendence_status varchar
I am using codeigniter v 3.0.0
it's easy to create a model to get the current time and save it in the database when the user check in/out.
but the problem is that, if the user was absent for a day or more , then the system will not create a record for those days.
moreover, i can't create the records beforehand. since i don't know when the user will have his/her vacation and working days may differ.
what is the best way to create and manage those daily records?
One possible solution may be to allow the employees to do their check-in each day normally which would populate the database for those days.
In order to add the absence records for those who have not checked in you could use CRON or something similar to schedule a task at perhaps midnight each day. Use this task to target a url that would run a method in a controller that will check employees against the daily records. Obviously for those whom have checked in no action will be performed, although for those who have not and are not marked as on vacation or not working you update the database to add the absence records.
With a system like this you would typically invoke the url to perform the update using whatever system you use with wget or something similar to 'load' the url and force it to run. A security consideration also would be that you'll want to add in a secret key as a GET parameter or something similar so that the method can check that it's being invoked via the task and not e.g. someone visiting the url by comparing the GET parameter with a stored key that you've set.
So I'm new to Laravel and trying to make a permissions system for the users on my application. Here is my approach:
1) Place a column in users table with the name 'permissions'
2) Create a table of permissions with columns id and page-name
Here's how it will work:
Each page will be assigned an ID. For example, the page Manage Accounts has id 1 and the page Manage Customers has the id 2 in the permissions table.
In order to give user full access to Manage Accounts and view only access to Manage Customers, I will make the following entry in the permissions column for the user 1.1111,2.1000
Now when the user will land on the Manage Accounts page, I will get the page id for the current page from the permissions table, i.e. 1. I will then convert the string value from the users.permissions column in the following format: array('1' => '1111', '2' => '1000');. Now I can get the user permissions saved against the ID of the page by $permissions['1'];.
I will then have a function to parse the 4 digits and get boolean values for the following in the exact order:
$canView = true;
$canAdd = true;
$canEdit = true;
$canDelete = true;
Now inside my page, I can easily put checks and display items accordingly.
Questions
1) So first question. Is this a good approach? Or are there better ways for going about this? I like this approach because I only have to add one more table in the database and it will only have as many entries as there are pages on my application, which aren't many. And it also means that I will only have to access the database once and I can then keep on using the values in the variable.
2) Should I create a separate class for permissions? I'm new so I don't completely understand the Eloquent class. But is that something I should be using for this? Or should I just add the functions that I need to create to the users class?
3) Where should I store the values of $canView, $CanEdit etc. Should I place them in the class for permissions and create an object for it? Or should I just use the Users class and access them using Auth::? I do not want to use Session, I don't think it to be safe.
4) Can I somehow have the permissions autoload every time a page is opened? I was looking into beforeFilter, and thinking of creating adding it to the constructor of each controller. Is that a good idea?
Thank you so much for your time and help.
Cheers
Why reinventing the wheel? take a look to https://github.com/Zizaco/entrust
I'm currently working on a website which will have many users on it. These users are stored in a table with each having a unique id. The website will contain projects that the users can complete and these projects are stored in a separate table with unique id's as well.
I need to make the users have a page they can view which will display a list of all the projects they are currently working on.
To do this, I am going to set up another table in which each row will have the user's id as well as the project's id that they are working on. All of that will work alright but I would like to allow users to cancel their projects if they please. I am aware of how to do this, but I have read that deleting rows directly from a php script is insecure so the user used to access the database from PHP does not have 'DELETE' permissions. I am wondering if I should just delete rows at will when a user specifies which project to delete or if I should just have another field and simply mark each user-project row as being 'cancelled' in another field so I can work with them myself.
What you should do is, for maximum security is, have a parameter in the database table called "isActive", or something of that nature, that is a BIT data type to represent a boolean. If that boolean is false, then do not delete the project from the database, simply hide that tables data (do not display it on the site, but keep the data stored in the databse). That way, not only is your database secure from malicious users who would like to destroy data, but projects can also be "re-instated" if they wish to re-instate it. If the project sits around for a certain period of time, say, 14 days, just have the server delete it, not the user, if you wish. This worked for me in the past.
Hope This Helps!
The most common approach to this problem is to have a field in the table that can be used to mark a record as deleted. This would be the only access the general user would have to the table as far as deletion goes. Some people also have a full delete, which states clearly that it will never be accessible again after the operation is completed.
Personally, I prefer to retain full delete permission to administrators allow the user to only mark records as deleted. If you're concerned about space, add a last accessed field as well, and schedule at set intervals a call to perform a full delete on any records that are marked as deleted and have not been active for a certain amount of time.