I've seen a lot in coding in my life, but nothing like this yet.
Does someone have an idea what practice/tool this is, or keywords relating to it?
My first guess was something related to kerberos/kdc, but doesn't seem true.
I have a webserver serving http with unknown/lost source code.
Behaviors:
When loading the pages for the first time, the webserver request a 301 reload to a certain kdc server (see url below) and sets two permanent cookies with identical values (PRXY_ID,PRXY_SN), and one session-temporary when visiting the login page (LOGIN)
Every time when loading the login page, form element id's (like username/pw) change in no visible pattern. My guess was that either the server randomly assigns these, and keeps track in a session-database with the the translations to the actual internal element id, or it is somewhat encrypted with the login-cookie, which is server-assigned - but since this cookie stays the same during the session reloads and not the id's, it would have to be salted before encrypted.
For every page load, the server attached certain query parameters to its url:
sample.com/kdcs/s56/HOME?SH=410488;SPP=353555;R=322450
The server keeps track of the transaction order. For example you can't send a logout post request, without first loading the profile page, with its logout button visible.
I'm grateful for any help on this.
I have a PHP website of 6 pages and I want to have a functionality such as this:
The website is a little quiz game where you need to get through 5 trivia questions per page and the final page displays the highscore. The score is based on how fast you got there as the pages have a timer.
But I found out about a cheat I want to fix. If you simply type in the URL highscore.php or question5.php, you can get there faster without having gotten through the first few pages.
Is there some way to fix this?
Track the state of the quiz on the backend, e.g. track which questions have been answered yet. When the user tries to access a page that would require a previous page to be completed first, redirect the user to that page instead.
You can achieve this with a Session.
An even better solution than having six pages would be to have one page instead, e.g. quiz.php and then funnel all access through this page. This will make it easier to track progress because you don't need to copy and paste the code to the individual pages.
On a side note: you also want to track the time the quiz was started on the backend.
It's not that hard, just a careful coding is all you require.
Firstly, start a session and set it to an initial value, say 1, that means the user is in page 1. If he submits the answer, and then the user loads any other page in your website, create a script to call the same session value and use header("Location:page2.php")to force a redirect to page 2 or the page he is supposed to be in.
If the session is removed somehow then use isset() to check if it exists, if it doesn't start from the beginning.
I have a logging application. You click the "Log" button, it takes you to another page with all of the forms etc. After I click "Submit" on this page, it submits to my database and redirects back to the home page. What I want to happen is when I click "Submit", it redirects to home page, and then has a pop-up that says something like "Thanks for the submission!". I've looked through the forums but can't really find anything specific to this application. Thanks.
There are a ton of ways to do this. The general idea is
The home page must contain code that displays the "popup," but only under certain conditions (e.g. a flag is passed somehow). Normal access to the home page should not trigger the condition.
The DB submission page must trigger the aforementioned condition when redirecting to the home page.
The "condition" could be as simple as setting a variable in the querystring, e.g. http://domain.com/home.php?showConfirmation=true. The problem with using the querystring is that the user could bookmark it and see the confirmation every time he uses the bookmark.
Another way to set the condition is to set a cookie, session variable, or pass the data via form/post. All of these have advantages and disadvantages.
You could also do it some fancy way, e.g. perhaps your site needs the general capability of displaying one-time messages. If the user is registered and authenticated, you'd be able to look up a DB table to see what messages are left to display to the user, and the home page would be coded to automatically display them (marking the DB record so that it doesn't get displayed again). The DB submission page would add the record for the confirmation message, and in addition you could use this feature for other types of home page messages that you dream up later, e.g. special promotions or new features. (I don't recommend building features you don't really need).
Send a paramater in the query string.
//home-page/?registered=1
Or you can set a cookie and check for the cookie if its set.. show the popup and delete it when user clicks on close popup.
Well, my problem is what the title says.
I have build a small application (php + mysql), to test my skills in an e-commerce environment - 6 pages in total.
Each page after the 1st, relies on an id to retrieve/save data. This id is passed usually as hidden form field between pages.
On top of each page i have a small script that checks in what state is the selected id (2 checks actually.... a) if user has reached the last page/step of application and b) if a fantastic payment has been completed for this user) - if both of these conditions are valid, then i redirect user to a thank you page, stating that his process is already completed and he can choose to start over.
Yet i have problems with hitting the back button on my browser.
Hitting the back button once, works good - validation check forces the redirect i have implemented in my code.
But hitting the back button fast for 2 or more times, break this script - leading to lost records in my database - in live environment these will be purchases.
So my question is this: what measures should i take to prevent the "back hitting user" of duplicating/deleting/overwrite data records in the application.
I am looking for ideas and strategies.
Check wether the user is eligble for the thank-you page on any of the pages. You can do this with sessions or by storing a flag into the database.
If a user that has finished the checkout already moves back more than one step you can check on that page if the user has already the checkout done or not - an react according to it.
I don't think is a good idea to pass variables from pages in post forms. Most likely you should make a good use out of sessions, paths and database.
What I'm trying to say is to save all info in a good structured database, every step has to be separated, that way you can always return to any step and load that step info from database without losing or breaking anything.
Since is an e-commerce website you can't afford to make a double payment or errors, since one single error can lead you into losing that client.
After finishing the forms you can save a field in database and tell other scripts to redirect the client on another page since he finished.
I am building a social network site in PHP/MySQL/jQuery. Once a user is logged into my site, I would like to query the DB and get an admin announcement if one exist. This will be a message box that shows on the page to all users but it will have an X to click on it and not show it ever again until the admin post a new announcement message. So if you never click the X and there is announcement messages that exist in the db, it will always show this message box on your page, however if you did cli9ck the X to close the box, then you come back to the page it will not be there, unless there is a new admin message posted.
I know there is several ways of doing this but I am looking for the most efficient way.
One idea I have, if I add an extra mysql field onto the user's table "admin_message" and mark it as 0, then when I post a new admin message it will change the record for every user to 1, if admin message is set to 1 then it shows on user's page. Then when the user clicks the X to hide the box, it will update there user table row and chnage the value back to 0.
Another idea I have is to use cookie's to check if a user has chosen to hide a message, i think this would be faster but maybe not as good, since user can log in with differnt computers and if a new message is shown, they may not see it right away.
So I am just wondering if it is a bad idea to use the extra database field? If I had 1,000,000 users, when I posted a new admin message, then I would need to update 1,000,000 rows to make sure everyone can see the message. Is there a better way? Also once a user logs into my site I will use a session to store the value of them seeing or hiding the message instead of looking at the DB on every page load.
UPDATE
Sorry I think my post might of been a little confusing or not clear on what exactly I meant because most the responses are catered to a message system which this is not anything close to.
Forget the message word please I will try to explain with a different word. Let's say there is 1 admin on the site, that is the only admin who can post a message to users to see. The users will only see 1 message, if there is 2352345234 messages posted over the lifetime of the site, it won't matter, they will only see 1 message, the newest message.
Now some users who log in and see this message "div" on the page might get tired of looking at it, so they will be able to hide it from ever showing again.
It will be as simple as a yes or no for showing this message on there page.
However if I decide I need to post a new admin message for all users to see, then even a user who chose to hide and not show the admin message will still see it again until they choose to never see it again.
Two simple solutions are as follows:
Good: Check the users cookie, if it contains a flag indicating the message was displayed don't display the message, otherwise display it. When the user closes it, update the cookie. Pros: absolutely simple. Cons: The user might see the same message twice depending on if they clear their cookies or log in from another machine.
Better: Store a flag in the database somewhere (you can store it in the admin user table for now, and down the line break it out into another table). When the user logs in, 1) save this flag to the user's cookie or session, 2) update the database, 3) decide whether the message needs to be shown. When the user closes the message, updare the cookie/session and DB. Pros: User never gets shown the message twice. Cons: slightly more involved as you need to maintain the flag in the db.
Implementation details:
For the flag, you could use a message id as suggested already, or more than likely you are already retaining the user's last login timestamp and could use that.
Every user could have a last_message_seen, so you have to query "new" messages (message_id > last_message_seen) for your user. If you [X] close (or timeout), then your javascript can check new messages and so on...
The other idea is to have that last message seen number in the javascript environment, but in that case it will be reseted (recalculated) when you refresh/abandon the page, and if it's not on the DB your user can miss messages inserted between last page load and this refresh.
Or... it can be in the Session, so you don't miss any. When you logon, the number is reseted to some "normal" number, let's say: last message, or message after (now - 1h), or whatever...
You are keeping a login time for the user right? Like a last_login datetime?
So get all messages where date_created >= last_login. Display them, then update the last_login time to now().
I would use idea #1. I wouldn't use a bool-field to check whether the user has read the message, I'd use a datetime-field, with some default value. If field == default, unread. When read, set field NOW().
That way you know aproximately how fast your users read the message.
EDIT:
after your edit, I'd still use the same mechanism. The message needs a field to find out whether or not is read. If the users clicks the X (to close), update the db and mark the message as read.
If the admin posts a new message, this will popup.
You also need a creation-datetime for your messahe, cause if a user did not close the previous message, and the admin posts a new one, only the latest message can be shown.
EDIT2:
In reply to this comment:
Even if a user missed am message, only
the newest should be shown. Maybe I am
misunderstaning but it sounds like you
are saying to basicly mark a message
read 100,000 times is 100,000 users
click the X and I think it should be
more on the user table, show or do not
show message box, not on an individual
basis
something is not locigal in your theory. You want to save the "show/don't show" as a setting, but you want to show the message anyway. How do you know when to overrule the usersetting and when not without remembering whether the system showed the message to the user?
Even if you want to just show it once, you'll need a field in the database (on message-level) to store whether the system showed the message to the user or not.
I'd recommend having a admin_message_queue table. It'll have a message body, a user ID, and a message ID. When you post a new admin message it'll add a record for every admin user to that table. Then when they log in you simply select all admin_message_queue rows where user ID = the logged in user.
To get rid of the message you'd just have the close button trigger an AJAX callback to a method on the server that takes the message ID. That method will delete from admin_message_queue where message ID = the one posted in and user ID = the user ID from the session. That way a user can't delete messages for someone else.
Doing it this way saves you from having to keep around rows of viewed messages. Why toggle a bit to hide it for someone? You'll end up keeping around lots of data that's no longer used.
Updated after question update:
Sorry I thought you were trying to show messages to just admins. You could keep this same logic for displaying the most recent message to all users, too. Simply have a table with a userID, message text. Whenever you post a message it will go through and overwrite the message text for all people that have records still existing (people who haven't hidden the message) and add rows for other people. When they hide the message delete that user's row.