Magento 1.6.1
I have set up Authorize.net (AIM) for the client's store. Previously they were using saved CC method and entering information manually in Authorize.net's merchant terminal.
Most of it is working as expected, however for transactions that are flagged as 'Suspected Fraud' by Authorize.net, if the client does not update the transaction manually before the authorization expires, using 'Get Payment Update' in Magento fails because the transaction is expired (I believe it's five days for an authorize only transaction).
For the client, it seems the only way to update this order in Magento is to simply delete the order, as it doesn't appear the Paygate model knows about expired transactions. Performing 'Get Payment Update' simply returns 'There is no update for this payment'.
I have already modified the file: /app/code/core/Mage/Paygate/Model/Authorize.net to have the correct API URL as described in issue #27117 ( http://www.magentocommerce.com/bug-tracking/issue?issue=12991 - must be logged in to view ). This resolved the button not working for all other orders; however this does not fix the issue I am describing.
Is anyone familiar with Authorize.net's AIM API so that we can update these orders in Magento to something that makes sense (canceled, etc.) without having to delete the order? I am thinking it should be a case of adding a new order status to Magento, checking the update for an 'Expired' status, and setting the order to the newly created order status.
-- edit --
I just ran a diff for the file mentioned above and noticed that Magento 1.7.0.2 includes the _isTransactionExpired() method which seems like it would be the fix. Can it be as simple as updating this model with the newer version?
In this case, I manually included the _isTransactionExpired() method described in my question to the app/code/core/Mage/Paygate/Model/Authorize.php, and things appeared normal and it was seeming to work as expected.
It's now been a month and a half, and I've not had the client come back to tell me things are not working, so I am assuming this fixed the issue.
Related
Long story short: I have hacked jasny/sso to work with Laravel. It works extremely well except when the primary/root session has expired.
I have the primary/root authentication set to "remember", so it can reauthenticate from the cookie when the session has expired.
When the 'attach' action happens on the SSO server and the primary/root session has already expired, I am running Auth::check() to bring the session back to life so that it can be attached properly.
All of my debugging indicates that everything is working exactly as I need it to except for this one little detail:
The new session generated by the 'attach' action is never written to the database because the DatabaseSessionHandler thinks it already exists. It is running an UPDATE instead of an INSERT.
As a result, my SSO client session attaches to a non-existent SSO server session.
For the life of me, I can not figure out why it thinks this new session already exists nor how to get it to correctly insert into the database.
Can anyone tell me why a new Laravel 4.2 session would be detected as "exists" and run UPDATE instead of INSERT on save()?
EXTRA DEBUGGING ATTEMPTS --
Attempt #1: I have tracked this to a false attachment to an expired session that hasn't been garbage collected yet. What I don't understand is how this session is being loaded while a different session ID is being presented. If this were the result of the migrate() or regenerate() methods, "exists" would be set to false, and it would save correctly. Somehow, it seems that the session ID is being updated without resetting "exists".
Attempt #2: The answer was staring me in the face the whole time. I kind of understand the downvote now. (see my answer below)
I was dramatically over-thinking this as I tried to uncover the mechanism behind the behavior instead of testing what looked like an easy solution:
If I call Session::setExists(false) prior to Session::save(), it will insert the new session correctly.
EDIT: If wrapped in an if-statement for Auth::viaRemember(), I can check if the auth happened via session or cookie/remember. If true, then I want to set "exists" to false.
Recently I have upgrade enterprise magento to 1.13.0.2. Also set up payment gateway as it is mandatory.We are using cybersource payment gateway. On checkout page shows an error 'This payment method is currently unavailable'.
Generally this means that the payment method is properly setup but is not enabled in the backend admin panel.
Navigate to...
admin/system_config/edit/section/payment
Or if your payment method settings are in a custom route search your core_config_data table for it:
SELECT * FROM core_config_data WHERE path LIKE '%cybersource%';
OR similar...
Find the value that corresponds with 'enabled' and ensure it is set to 1 for default scope and all the store/website scopes you're testing.
If the value for enabled/active is not present in core_config_data you need to find your payment method route through admin and save it that way as the configuration entries are only populated after the initial save.
Ensure you flush cache and check if the issue persists.
If it does, search your repo for the error message text and var_dump/die above to understand what's missing.
This might cause by following reasons;
1) Ips are not allowed
2) If its in stage/test server, this issue may come if the site is password protected
3) SSL is not properly installed or have error(If ssl is using)
Before checking above points make sure you have added correct merchant_id and transaction key;
php tools/merchant.php -i your_merchant
My issue was due to #2.
A web site I have published is generating the error stated below when a valid user submits form content to be stored in the database:
Forbidden
You don't have permission to access /index.php/user/add on this server.
Additionally, a 404 Not Found error was encountered while trying to use an
ErrorDocument to handle the request.
This is a private web site. All users have to log-in. Some users can add content. Using CI sessions there is an added field of edit, with a value of 0 or 1 retrieved from the user's record in the user table, copied to the user_data session array at the time of log-in. The variable $this->session->userdata('edit') is used for if statements in the controller and views. Value of 1, user will see links that will bring up views (forms) to edit or add content.
This is a snippet for how I am using the variable to set menu items:
<?php if ($this->session->userdata('edit') == 1) { ?>
<li>Add</li>
<?php }; ?>
This is the basic structure for the processing of form data. This function is in the controller file user.php:
function add(){
if ($this->session->userdata('logged_in') ){
//runs form validation
if ( $this->form_validation->run() == FALSE ) {
//if false, redisplays the form and data with failed fields highlghted
}//if
if ($this->form_validation->run() == TRUE) {
//processes the data and stores in the database
}//form validation run
} else {
redirect ("user/login");
} //if...else
}//add
Examining the database after one of these Forbidden errors, no data is inserting. A redisplayed form due to validation error(s) is not happening either. These factors lead me to believe this is a server problem more than a CodeIgniter issue. If you look at this link it shows a screen shot of the error received in the browser (either Firefox or Chrome, other browsers not in use yet), it is not the usual CodeIgniter appearance for an error generated from a mistake in CI code.
The add/edit content forms are working well. As stated above, the error occurs at time of form submission. As well, it is only happening on the hosting company's server. I have checked the permissions of user.php and they are 644 like the rest of the files.
What are possible fixes? If it is a server issue, what do I look for or ask my hosting company to look at? If it is a CI sessions issue, in the documentation CodeIgniter states it uses a system different from $_SESSION super global. Is it wise to copy the user data to that array and have the code look up the data from that variable array? Or do I create a distinct array and save the keys there?
Revision and Solution
I retested the connection to the database associated with this project. I could connect. Taking things a next step, I could select records but not insert. I performed those tests with raw, simple statements.
Examining privileges for this user and the database, I discovered that while All Privileges was checked, none of the individual privileges was checked. (See this screen shot.)
I ignored the All Privileges check-box and manually checked each of the other boxes. Conducting small tests like the ones outlined above and then interacting with the form on the site, I am getting results I expect.
Things I don't understand:
How can All Privileges be checked and none of the other check-boxes checked?
I have gone back and tried to check All Privileges and then uncheck the others individually. It's not possible. From interacting with Panelbox on this host often to set-up users and associate them with a database, I know it is not usual for the state I found described above.
Programmatically, since there is only one user and set of privileges associated with a CodeIgniter site, how was the admin for this site able to insert 5 records in the database before a Forbidden error started being returned from the server?
I did not outline it when I first posted this thread, but the Forbidden error did not happen right away with uploading and running the site from the server. Since the admin was able to submit five completed forms perfectly before starting to receive errors, I presumed it was a Sessions problem. This contention was also arrived at because sometimes deleting the cookie and then logging in, I or the admin was able to submit a form and the data was inserted in the database.
Thanks for taking the time to read this.
Test user privileges associated with a database often. Sometimes things change.
I just move my Magento store to my localhost environment for testing use, I also using Git to maintain code, but after I move all the files to my local environment, I can't login my admin page, but I can still see my frontend pages, and the git, the database, seems works well.
When I type a wrong admin/password to my admin page, it still gives me "Invalid password".
But when I enter the right one, it just refresh the page and stay at the login page, nothing happens.
Does anyone has met this problem before? Has any ideas?
Thanks in advance!
Although this question is old, all the above answers did not work for me until I did one additional thing.
Follow the very helpful answers already posted (summary):
Change your base_url to http://127.0.0.1/ for secure and unsecure path.
delete files in var/session and var/cache
alter your Varien.php file accordingly - depending on your version of Magento.
And then:
Finally, use http://127.0.0.1/your/site/folder/name/index.php/admin
It was the lack of the index.php/admin ( instead of using http://127.0.0.1/site/admin ).
I hope this helps someone else.
Recently started using Magento for a project and came across this issue. I was left frustrated by the fact there are at least ten or more different workarounds suggested on the net and it took a bunch of trial and error to find one that did the job. Seemingly some workarounds work for some versions and not for others. No one explained why or how the problem occurs and the most popular solutions involve hacking the code base or using a different url, which shouldn't be necessary.
The cleanest solution I found for Community Edition 1.9.1.1 was editing two config values in the database:
update core_config_data set value = NULL where path = "web/cookie/cookie_path";
update core_config_data set value = 0 where path = "web/cookie/cookie_httponly";
The cookie path is actually NULL by default on a fresh installation but it must either be NULL or empty string.
The behavior arises because some browsers including Chrome have issues creating cookies with a localhost domain, this means that when Magento calls session_start() the session identifier cookie never gets created and as a result information can not be passed from page to page. The login procedure is actually successful but the next request doesn't know about it, hence why you get redirected back to the login screen. There are no errors because Magento doesn't account for this edge case as a possibility.
If you do not provide a domain value when creating a cookie on localhost then the browser has no problem with it. Unfortunately just setting web/cookie/cookie_path to NULL is insufficient, because Magento's configuration class resolves this as an empty string which is enough for a real domain to be set later in the code:
if (isset($cookieParams['domain'])) {
$cookieParams['domain'] = $cookie->getDomain();
}
This method eventually uses the current HTTP host to resolve a real domain for the cookie, and the browser therefore wants nothing to do with it. However if we disable web/cookie/cookie_httponly then Magento will not perform this additional step, $cookieParams['domain'] is unset and no domain gets passed as a session parameter, thus allowing the session cookie to be created and things to function as they should.
Note that any time you modify the database configuration you must delete the contents of /var/cache/ for the changes to be reflected.
If like me you don't want to have to comment out code, or even make configuration changes, then I created an extension which overrides the getDomain() method shown above and returns null if we are on localhost, this should be somewhat more future proof and result in no collateral damage.
http://www.mediafire.com/download/q39p4k95s5tlght/LocalCookie.zip
Try deleting the contents of the cache folder /var/cache. Clear your browser cookies and try. Also, if you have copied down the database from your server, you may need to manually change the base urls (secure and non secure) as well as the cookie domain in the core_config_data table. Do this manually if you need to. e.g. web/unsecure/base_url with production value of http://www.mywebsite.com/ becomes "http://localhost/"
When ever I have had this it's because of this or cache. Ensure the cache folder is ignored in git hub if it's not already.
1.you need remove the cache
rm -rf var/cache/* var/session/*
2.change the domain form core_config_data
update core_config_data set value="http://127.0.0.1/" where path="web/unsecure/base_url";
update core_config_data set value="http://127.0.0.1/" where path="web/secure/base_url";
do these steps :
1: go through: xampp\htdocs\magento\app\code\core\Mage\Core\Model\Session\Abstract**
2: open **Varien.php file
3: make comment line number from 87 to 104 save it and try to login...
Had the same issue, but the fix was changing DB values:
UPDATE `core_config_data` SET `value` = 'http://127.0.0.1/example/' WHERE `path` = 'web/unsecure/base_url';
UPDATE `core_config_data` SET `value` = 'http://127.0.0.1/example/' WHERE `path` = 'web/secure/base_url';
Then in browser http://127.0.0.1/example/admin
Same problem! I fix my problem after remove/replace static domain in core_config_data Table
web/secure/base_url
web/secure/base_link_url
web/secure/base_skin_url
web/secure/base_media_url
For me, running it on IIS (I know, not officially supported):
Although other suggestions kind of worked I found the best solution was to enter a new A record for me domain like
127.0.0.1 local.example.com
Then in IIS add the binding
local.example.com
to my site and it worked perfectly.
I found there were errors when actually trying to login to the customer account more than admin but believe it still applies.
Im having the exact same problem as this user:
http://www.magentocommerce.com/boards/viewthread/284012/
Although no solution was posted.
When I try and create a new order , all works fine except I cannot choose a custom group. Checking anything else in the dropdown results in the loading dialog , and it then resetting to the default value.
No errors are thrown in the logs.
This , it seems is related to payment gateways. Specifically in this case , SagePay. Removing the SagePay plugin solved the issue.
In 1.3 we were using a different plugin than what works in 1.4.