I searched everywhere but I couldn’t find a real answer about this specific case.
Let’s say we have registered two pages with fragmented address (I mean they are not contiguous) in the same page directory, then registered directory address in CR3 and activated paging with CR0.
If a loaded program P1 loaded at 0x0 in the first page try to access an address higher than the max address of page 1, will it be automatically mapped to page 2 or do we need to setup an interruption ?
Thanks
If a loaded program P1 loaded at 0x0 in the first page try to access an address higher than the max address of page 1, will it be automatically mapped to page 2 or do we need to setup an interruption ?
Nothing is automatically mapped.
When you access anything at any virtual address, the CPU splits the virtual address into several pieces - e.g. an "index into page directory", and "index into page table" and an "offset in final page". Then it uses most of these pieces as indexes into various tables.
If something isn't present (if the page directory entry at "page_directory[index_in_page_directory]" says that the page table isn't present, or if if the page table entry at "page_table[index_in_page_table]" says that the page isn't present) then the CPU triggers a page fault exception.
The CPU also does other protection checks at the same time - e.g. for a write, if the page directory entry at "page_directory[index_in_page_directory]" says "read only" then you get a page fault for that too.
Of course the page fault handler can do all kinds of things, including "auto-mapping" a page that wasn't present and then returning to the instruction that caused the page fault (which will cause that instruction to be executed a second time with no problem because the page is mapped now).
Related
For example I am testing a website and I found some invalid (error) pages. You visit the page and receive status code 500. But now if you reload the page or visit any valid page on website it just stuck on loading until you clear cookies of that site from browser. So maybe this activity make current user cookies/session invalid on server side I guess so you clear cookies and reload the page and it becomes normal. In terms of severity in which category we can identify this issue.
There are lots of way to exploit this bug in real life.
For Example - Send this page link to victim so He/She might think that whole website is down and you may lead them to other optional sites or your own website for your personal benefits maybe.
I would grade it with this CVSS-vector:
https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:L
which results in a score of 3.5 (LOW)
Reasoning:
Attack Vector - Network: You send the malicious link to the victim via internert
Complexity - Low: It is rather easy to spot the vuln and sending a link is easy as well
Privileges - Low: You need an account on the page to find the vuln
User interaction - required: Victim needs to click on the link
Scope - unchanged: nothing changes beyond your session in the web application
Confidentiality+Integrity - None: Not affected
Availablity - Low: Only single session is affected
I understand how to differentiate if the page is user page or supervisory page using the bit, but what is the difference between these pages and how is it related to the user mode or supervisory mode ?
Typically an OS has trusted code (e.g. the kernel) which might be called "supervisor code" and "potentially malicious, less trusted" code (e.g. normal processes) which might be called "user code".
Often paging is used to protect trusted code and its data from the "potentially malicious, less trusted" code by allowing pages to be marked as "supervisor only", so that if "potentially malicious, less trusted" code attempts to access something that was marked as "supervisor only" it causes the access to be denied and triggers exception ("page fault") instead.
In other words, the "supervisor" bit (in page table entries, etc) determines if user code can access the contents of the page.
Our users return to our web site from an external site, to a URL which is passed to the external site as a user leaves our site. Returning to our site involves a status update which is persisted to the application's datastore.
I have implemented a check upon return to our web site, which prevents a multiple write to our datastore and thus makes the operation idempotent.
A typical order of events is:
First post to our landing web page (web page instance 1 is constructing)
First post passes check (data not processed before)
Data persistence begins (still in the web page constructor)
Second post to our landing web page (web page instance 2 is constructing), which is in the same session and browser window as the first post
Second post fails check (data has been, or is being, processed already)
Web page instance 2 constructor completes (with no persistence to datastore) and web response is served to the user
Web page instance 1 constructor completes (after having persisted to datastore)
The user does not see page instance 1 in their browser.
The end result is that, even though the second post is made after the first, the second post "completes" faster to the user and the user's web browser shows instance 2 of the page, not instance 1.
My questions are:
Is there any way I can have the first, datastore-processing, page instance shown to the user (and thus "throw away" the second page instance)?
If so, can this be done without using AJAX?
I would appreciate any assistance greatly.
My development environment
Web framework: Wicket 1.5.7
Java: 1.6.0_33; Java HotSpot(TM) Client VM 20.8-b03
Web server system: Google App Engine for Java version 1.6.6
Operating system: Microsoft Windows XP Home Edition version 2002 SP3 (version 5.1 running on x86; Cp1252; en_GB)
IDE: NetBeans IDE 7.1.2 (Build 201204101705)
Thank you to #svenmeier for your first tip. My solution follows this approach. I have decided to have page instance 2 wait repeatedly if necessary instead of following #Carl-EricMenzel's suggestion of redirecting.
Referring to my order of events as set out in my question, step 6 is replaced by:
6.1 If data is being processed already, page instance 2 waits repeatedly whilst checking after each wait.
6.2 After all the waiting, page instance 1 will have completed step 7 (and 8). If not, then page instance 2 completes construction.
6.3 If the data processing of instance 1 succeeded then page instance 2 shows success to the user.
6.4 If the data processing of instance 1 failed then page instance 2 processes the data and shows the result (success/fail) to the user.
My Magento Verison is - 1.4.1.1
I am having two problems:
1) When I am going through various steps of Onepage checkout (registration, billing, shipping, and payment tabs), sometimes during this process I am redirected to the cart page. There is no error, no exception, no report gets generated in var/report. I dont know how to debug it. Aren’t there any logs I can look for?
2) In same Onepage Checkout process after clicking on place the order (last step) , some times it redirects to the cart page, sends an email saying that the order failed with the message:
Quote totals must be collected before this operation.
To resolve it I commented this line in prepareRecurringPaymentProfiles in the file magento/app/code/core/Mage/Sales/Model/Quote.php, which solved the problem:
throw new Exception("Quote totals must be collected before this operation.");
I dont know if these 2 problems are related or not. But I am not having the 2nd problem now but having 1st one quite frequent. What could be the reason and how to resolve it?
further update-I checked the firebug trace, It is 500 internal server error which comes sometimes in any of the step in one page checkout. I was able to dig down into savebillingaction, saveshippingaction functions in onepagecontroller.php and found that error comes when $this->getRequest()->isPost() is blank , If it is 1 then it goes ahead, and goes to the next step else it redirects to cart, No I dont know why this is not 1 or is it because ajax is not able to send post data but I checked XHR request, Ajax send the post data every time (checked with firebug extension). Can Someone tell me What I could do next to troubleshoot. Where I can look for these Ajax Calls?
Shipping.phtml (any step.phtml) has JS at the bottom , How does it call OnePagecontroller saveshippingaction function ?
Since it's internal server error, try to access the error log of the server. Will tell you where is the problem. I' ve had the same problem in 1.7.0. In my example the problem was at /app/code/core/Mage/Usa/Model/Shipping/Carrier/Fedex.php
For anyone else coming across the "Quote totals must be collected before this operation." error, check your Apache logs for the reason of the 500 internal server error. If it's something like this:
mod_fcgid: read data timeout in 40 seconds
Premature end of script headers: index.php
process 26126 graceful kill fail, sending SIGKILL
..PHP is taking too long to respond. Usually its the onepage/checkout saveOrder action because it's quite heavy and often needs to connect to third party services (payment gateways, newsletter services like mailchimp, etc.). These calls to third party services can take a while, depending on the network state and might be the reason of PHP timing out.
You can start by increasing the timeout, but it's not a good permanent solution because you want to find out why this is happening in the first place.
New Relic is a good tool to monitor these calls (and a good tool to monitor your Magento store in general).
Firstly, commenting an error message is almost never the way to solve a problem, as you are just covering up some issue that may have severe consequences for your system.
Nailing down errors like this can be hard, but there are a few places to look first:
Did you install this system on a lower version and then upgrade? If so, how?
Are you using any extensions that modify the sales/checkout portion of the site?
Have you overridden any of the models concerned with this part of the site?
Have you changed the JS or HTML for the checkout?
If one of those is the case, you should review those changes for bugs. If not, try turning on the default theme for the site and checking out again. If the bug disappears, there is a problem with the theme that you are using. If it still appears, the problem is in code.
In that latter case, use Firebug to verify that the offending page requests result in Magento sending back "redirect" commands to the frontend. If that isn't the case, it may be some kind of JS error, but more likely you are ending up with invalid data in the system somewhere that causes Magento to choke during checkout.
Also (just thought of this, haven't tried it), try the multi-address checkout. As I recall, it uses regular page posts, and may even have more useful messaging than the OnePage checkout. Please edit your post with your findings from the above so that we can help more if that doesn't do it.
Hope that helps!
Just in case someone gets the "Quote totals must be collected before this operation." error, and none of these solutions fixes their particular problem, I'll mention that mine was an issue with this:
skin/frontend/base/default/js/opcheckout.js
var params = Form.serialize(payment.form);
There was a JS error unique to this site which was clearing the Payment form and preventing JS from reading it's contents. The module or theme that you use will differ, but check to make sure that the payment form can serialize correctly. If not, then that could be your problem.
I had the very same problem on my store Princessly:
It takes about 20 to 130 seconds or even longer for "Submitting order information ..." to go through and redirect to the payment gateway such as PayPal, if at all, after clicking the Place Order button, last step of one page checkout.
If it doesn't go through, very probably because something timed out since it took too long, it will redirect back to shopping cart, leaving the customer an empty cart and a Pending Payment order, OR, it will give the exception of:
Quote totals must be collected before this operation.
Since obviously, well, something timed out and the script ends before quote totals are collected (which is just my theory), thus sending the Payment Transaction Failed Reminder email.
After 12 hours of research and debug, I finally found the culprit and the solution.
Magento enables RSS stock and new order notification by default, so every time Place Order is pressed ('sales/order' resources are then saved), cache is refreshed so RSS will be published. Cache cleaning can be very time-expensive for Magento. Therefore the solution is simple. Just disable RSS notification for save of 'sales/order' resources.
Find /app/code/core/Mage/Rss/etc/config.xml and locate this block:
<sales_order_item_save_after>
<observers>
<notifystock>
<class>rss/observer</class>
<method>salesOrderItemSaveAfterNotifyStock</method>
</notifystock>
</observers>
</sales_order_item_save_after>
<sales_order_item_save_after>
<observers>
<ordernew>
<class>rss/observer</class>
<method>salesOrderItemSaveAfterOrderNew</method>
</ordernew>
</observers>
</sales_order_item_save_after>
Simply remove or comment it out and refresh Magento cache in System => Cache Management => Select All => Submit.
Now it only takes 1 second or even less for my store to go through Place Order and redirect to payment gateway.
Numerical IDs vs names
As an example, which of these would you choose for identifying a single transaction, from a single bank account, for a single company:
/companies/freds-painting-ltd/accounts/savings/transactions/4831
/companies/freds-painting-ltd/accounts/1/transactions/4831
/companies/62362/accounts/1/transactions/4831
You idiot, something totally different! Crikey, did you even READ Fielding's dissertation?
Now, I think the 1st one is the most readable. If I have more than one company, or if I'm someone like an accountant managing multiple companies, it's immediately clear which company, and which account, I'm looking at. It's also more bookmarkable/emailable and would prevent 'fishing' for other companies by changing the company ID. I would want transaction IDs to be unique to an account (I.e. Both 'savings' and 'current' accounts could have transaction '1'
A 'company' will be my 'top-level', or 'first class' resource. Nothing at all would ever be shared between companies. As such, it would be the ideal candidate for a shard (or 'ancestor'/'namespace' in Google App Engine parlance). So I'd only have to worry about the account names being unique within one company. Every company could have an account called 'savings'.
Not sure what the situation in the rest of the world is, though LTDs or PLCs in UK would have a unique name, there could be many 'Dave's Window Cleaning' businesses (what's know as a trading name).
The business owner(s) could potentially opt for the top level /company/company-name URI to be public, and contain some basic details like their website, contact details etc, but everything below that would NEVER be accessible by search engines.
So my thoughts/concerns are:
1) Is it reasonable, when someone signs in to add their business, to say "Sorry, 'Dave's Window Cleaning' business is taken. How about 'Dave's Window Cleaning Portsmouth' (Having taken their location in another field)? My worry with this is that, for a more well known company, you're giving away the fact that they have an account with you. Or that someone could use that form to search for names. Perhaps not a biggie.
2) The size of the company name. Would it be reasonable for a name like 'Dave's Window cleaning, gardening, and loads of other stuff'? Thus creating a URL like 'daves-window-cleaning-gardening-and-loads-of-other-stuff/'
3) How to deal with someone changing their business name - I would approach it by creating a new company with that string ID, copying over everything, then deleting the old resource. The original URI would return 404 rather than redirecting - as you can't guarantee someone else won't want to take the now unused name, or even if more than one person has used the same name in the past.
4) Should the 'real' unique ID be an number in the back end, and for every request to be handled by first doing a query for what company ID this name actually related to.
5) The impact of searching for a transaction in the persistence layer.
6) The possibility of URL rewriting, but then that wouldn't work cleanly in GAE, nor would it solve the issue of ensuring company names are unique.
RESTful webservice vs RESTful website
So, we potentially have this lovely RESTful webservice that the latest snazzy iphone/android app can use (delusions of grandeur). But what about the main website itself? I note, right now, that the URL I see at the top of my page is not 'RESTful': /questions/ask is an action. There is no 'ask' resource on the server. It's more the state of the page, the preparation for POSTing to /questions/ - or if I'm editing, PUTing to /questions/{id}
I also note that Stackoverflow has URIs like /questions/362352/name-of-the-question, and that the latter part can be omitted, and one will be redirected to it.
Should I host a completely separate webapp that consumes my lovely webservice (from the same domain)? Do I even need a separate REST server, or can I rely on content negotiation (JSON/XML) and HTTP verb to select the right method (I'm using Jersey), and return the right representation?
So I could have /companies/aboxo/ return the whole HTML page (using stringtemplate.org) if it's a GET /,text/plain or test/html, and JSON/XML for others?
But what happens for 'add/edit/delete' transaction? Would GET / /companies/freds-painting-ltd/savings/transactions/?template=add be ok (or GET ../transactions/352?template=edit), and that would return the right HTML?
Thinking about this last detail is driving me mad for some reason.
Comments, suggestions, outright ridicule - all welcome!
Marcos
Rails solves the "id vs name" problem by displaying both in the URL but using only the id to actually identify eg:
/companies/62362-freds-painting-ltd/accounts/1-savings/transactions/4831
ie - for the ones that have a "pretty url" the function that generates your path write both the id and the name... but for your router, where relevant: you strip off everything thats not the id.
incidentally, it means your customer could actually write whatever they like into the URL and it'd make no difference:
/companies/62362-i_luv_blue_turtles/accounts/1-your_mum/transactions/4831
and your router still just sees:
/companies/62362/accounts/1/transactions/4831
:)
For a cannonical URI I suggest just /transactions/{id} as I presume the transaction knows what the company and account is. Therefore, #4 :-)
Is SEO a concern? I presume you don't want random folks off the internet googling for X company's transactions?! Therefore, I would just keep names (which may change) out of the URI.