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.
Related
I've designed a forum on my website that operates through AJAX requests therefore the URL does not change at all. You click a button, the AJAX requests a PHP file, and the response updates the client. This works for me - however, I need to know if it's possible to redirect a user through a series of AJAX requests after a form submission.
User enters forum.php page
User clicks on topic button (AJAX request to load threads)
User clicks on thread title (AJAX request to load replies)
User clicks on reply button (AJAX request to load text editor)
User clicks on submit (AJAX request to submit form)
At this point I want to redirect the user back to that specific thread - therefore I believe they would need to be directed through a series of AJAX requests. Is this possible?
Extra: Also if you believe this forum process is not efficient please let me know your opinions.
Seems you have a few options:
continue to use Ajax for the submit, so no need to redirect. (EDIT: sounds like you are already doing this, so the problem is probably you are discarding the content you want to display, rather than just hiding it temporarily)
implement a way to load a page directly to the forum. This would be in addition to the ajax call. You would track the forum ID, include it in $_POST parameters, and have the server redirect to the appropriate URL.
Generate javascript (or approriate fields/data for your fixed javascript to use) that will cause the page, when reloaded, to automatically make the necessary AJAX calls.
Skip Ajax and just use full page loads for everything
Mixing things up, by sometimes using Ajax and sometimes using a page load isn't ideal, but it is sometimes difficult to avoid completely.
Keep in mind what happens when user hits the BACK button or history in the browser. Do you want them to leave your app when hitting back? They can end up in a weird place mixing ajax/page loads. For this reason, people favor (4)
(2) is probably a lot of work.
(1) would be ok, and BACK button will just always take the user WAY BACK to some other website. Personally, that wouldn't bother me.
(3) would be a pain and also be slow, and then you get pretty weird forward/back behavior. Avoid.
(4) might just be best.
I am looking for a way to detect when a page is reloaded after clicking the back button, so I can selectively ignore errors. Let me explain why:
Imagine a page that displays some data, identified by an id:
/show/some/data?id=5
Initially, the id exists and the page is displayed. If the id does not exist, an error message is shown and an error is logged, because that should not happen and would indicate a broken link in the application.
Now imagine the user looks at the data, decides to delete it, and after deleting, uses the back button to go to the same page again (BTW this is not a hypothetical, I have seen this in my application). Now, the id is no longer valid, triggering an error. If I could distinguish between the initial page load and the second page load after using the back button, I could be more lenient in my error handling. My reasoning being that a broken (forward) link in the application is a fatal error. A broken link after clicking back (when there was none initially) is very likely caused by some action the user took in the meantime. In that case I would much rather redirect the user to an overview page than show an application error.
I believe one way to solve this would be to attach some randomly generated id to the url:
/show/some/data?id=5&rnd=<?php print rand(); ?>
and log the random ids that have been used in the session. If an id repeats itself, I can assume that the page has been reloaded, and selectively ignore some errors.
However, that would require altering many links in the application. I could also use javascript/jQuery to alter all links on the page to the same effect:
$("a").attr('href', function (i, h) {
return h + (h.indexOf('?') != -1 ? "&" : "?") + "rnd=" + Math.random ();
});
That's slightly less invasive, but still rather heavy handed for solving such a seemingly trivial problem. I wonder if there is or can be a self-contained way to do this. Is there any way for the backend application to distinguish if a page is loaded by forward clicking on a link or reloaded after clicking back? Or is there a more elegant solution with javascript?
There's no perfect solution for this since you're trying to (sort of) change a browser's behaviour. The simplest idea I can think of is setting a session variable with a list of deleted pages, and pushing the page IDs into it on the delete page.
Then, you need to update your error handler to additionally check for the presence of the requested page ID in the deleted pages list. That way you won't have to mess with URLs at all.
Here's an example flow:
user requests page id 1
app checks the db, it doesn't exist
app checks the session, it's not in the deleted pages list
error message shown, error logged on the server
user requests page id 2
app checks the db, it exists, show the page to the user
user clicks the delete button
ID of the page is added to the session list of deleted page and the page is deleted
user goes back (or types the url manually, this is a bonus feature)
app checks the db, id 2 doesn't exist
app checks the session, id 2 IS in the deleted pages list
error message shown, no errors logged
You can also take this one step further and track all the visited pages, so you'll know that if something was there a few minutes ago, and now it isn't, the user must have deleted it. This would allow you to handle more such events if needed.
A short tutorial in W3schools about PHP Sessions writes the following:
When you work with an application, you open it, do some changes, and then you close it. This is much like a Session. The computer knows who you are. It knows when you start the application and when you end. But on the internet there is one problem: the web server does not know who you are or what you do, because the HTTP address doesn't maintain state.
Session variables solve this problem by storing user information to be used across multiple pages (e.g. username, favorite color, etc). By default, session variables last until the user closes the browser.
So; Session variables hold information about one single user, and are available to all pages in one application.
I would like to ask you if there is something similar in Zoho Creator. The reason why I am asking is because I have an application with 3 pages (each page has an embedded form). Each page redirects to the other (1st Page -> 2nd Page -> 3rd Page) and passes data through them via openurl. The final result is an HTML Page with the data of these 3 Pages (they have a unique ID).
Let's say that I am in the second page and for some reason (electricity blackout, do another job and close the browser) I want to escape from the application and the next time to continue from the same point, is there any way to do that??
I can suggest you next way
On first page generate unique session Id for the user and pass this id as a parameter to next page in URL. You can crypt in this id pointer to record from first form for example..
so I've hit a potential problem in my site....it's a post-based system, with the posts being in text files. Uses some Javascript and a lot of PHP.
When you make a submission on the form on the homepage, you are sent to a page where data is posted and processed, but you don't see it because you get redirected back. Then the homepage is changed based on what the post you made says. All that was working fine.
But now I'm trying to add a new feature that modifies the post you made, based on a button you hit which submits a hidden form using javascript, and sends to another process and redirect page you don't see, and it works fine until the block that I realized today. I don't know how to specify that the post being altered is the right one.
I anticipate a good amount of users of this site, so my concern is what if user X makes a post while user Y is making a post, and the post of user X becomes the top post, so user Y's options actually change user X's post.....
I was thinking of adding to the main processing page (the one that happens when you first submit) a COOKIE or something that would make note of the number of the line that post will become, by counting the number of the lines in that file at the time and adding 1 to it. Then checking it against the user's number (each user has a number) to see if it's that user's most recent post....but the problem is I don't know how I would pass that value around to be read in the next page.
Setting a COOKIE is out I think because the page both redirects, AND reads and writes to files. The only output to the page though are currently var_dumps.
POST/GET is out because to my knowledge the user would have to do SOMETHING to submit it, and the user's not even going to see the page.
Writing to a file would be messy if lots of users are trying to get their own data.
I think what I may be looking for is SESSION variables...but I don't know anything about those except that they're used to login to pages, and this site has no login.
To make things more fun, when a user posts the same content within a minute of another user, the first user's post is replaced and it gets a little +1 next to it...which makes it harder to check it against the user's number....
AND in the end I'm trying to use AJAX (which I dont know yet) to make the updates in real-time...now THAT is going to suck. But for now I'm worried about my static little site.
Baby steps.
Any ideas how to go about this??
Use Session variables, just as you have alluded. They aren't just used by login pages, they are used by everything. Sessions are the equivalent of server-side cookies / server-side storage, so you don't have to worry (as much) about your users tampering with them.
If you want to make life more difficult for yourself, you can json encode your variables and store them as an object in a database or even flat text file. But really, read up on sessions.
All you need to know is session_start(); before anything else then $_SESSION['var']=$yourvar; to save data and $_SESSION['yourvar'] to retrieve it later (such as on another page).
I have an application that supplies long list of parameters to a web page, so I have to use POST instead of GET. The problem is that when page gets displayed and user clicks the Back button, Firefox shows up a warning:
To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier.
Since application is built in such way that going Back is a quite common operation, this is really annoying to end users.
Basically, I would like to do it the way this page does:
http://www.pikanya.net/testcache/
Enter something, submit, and click Back button. No warning, it just goes back.
Googling I found out that this might be a bug in Firefox 3, but I'd like to somehow get this behavior even after they "fix" it.
I guess it could be doable with some HTTP headers, but which exactly?
See my golden rule of web programming here:
Stop data inserting into a database twice
It says: “Never ever respond with a body to a POST-request. Always do the work, and then respond with a Location: header to redirect to the updated page so that browser requests it with GET”
If browser ever asks user about re-POST, your web app is broken. User should not ever see this question.
One way round it is to redirect the POST to a page which redirects to a GET - see Post/Redirect/Get on wikipedia.
Say your POST is 4K of form data. Presumably your server does something with that data rather than just displaying it once and throwing it away, such as saving it in a database. Keep doing that, or if it's a huge search form create a temporary copy of it in a database that gets purged after a few days or on a LRU basis when a space limit is used. Now create a representation of the data which can be accessed using GET. If it's temporary, generate an ID for it and use that as the URL; if it's a permanent set of data it probably has an ID or something that can be used for the URL. At the worst case, an algorithm like tiny url uses can collapse a big URL to a much smaller one. Redirect the POST to GET the representation of the data.
As a historical note, this technique was established practice in 1995.
One way to avoid that warning/behavior is to do the POST via AJAX, then send the user to another page (or not) separately.
I have been using the Session variable to help in this situation. Here's the method I use that has been working great for me for years:
//If there's something in the POST, move it to the session and then redirect right back to where we are
if ($_POST) {
$_SESSION['POST']=$_POST;
redirect($_SERVER["REQUEST_URI"]);
}
//If there's something in the SESSION POST, move it back to the POST and clear the SESSION POST
if ($_SESSION['POST']) {
$_POST=$_SESSION['POST'];
unset($_SESSION['POST']);
}
Technically you don't even need to put it back into a variable called $_POST. But it helps me in keeping track of what data has come from where.
I have an application that supplies long list of parameters to a web page, so I have to use POST instead of GET. The problem is that when page gets displayed and user clicks the Back button, Firefox shows up a warning:
Your reasoning is wrong. If the request is without side effects, it should be GET. If it has side effects, it should be POST. The choice should not be based on the number of parameters you need to pass.
As another solution you may stop to use redirecting at all.
You may process and render the processing result at once with no POST confirmation alert. You should just manipulate the browser history object:
history.replaceState("", "", "/the/result/page")
See full or short answers