View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002194 | OXID eShop (all versions) | 2. ----- eShop backend (admin) ----- | public | 2010-11-03 11:19 | 2010-12-14 18:33 |
| Reporter | mbrotzeller | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | unable to reproduce | ||
| OS | Suse Linux | OS Version | 11.3 | ||
| Summary | 0002194: Login for Admin does not work after Setup due to Template Modification | ||||
| Description | Our Shop (EE, 4.4.2) has some modifications, an additional field to oxuser. When i install with our modified codebase via oxid setup, i can proceed all the way through and generate a new database for the shop. At the login prompt, i enter the very credentials i entered during setup. Then i get a message that username and/or password are incorrect. It took me a very long time to find out that this is due to shop templates changed (no admin templates were modified), thus triggering the retrieval of the additional field from oxuser - therefore failing the query to retrieve the user. After i found out, i reset the basic templates to factory state and login worked. I suggest catching that error and not pretending that user login does not work, but just say "an unrecoverable error has ocurred" - that way the user knows what to look for. Additionally, the admin area probably should not be dependent on shop templates. | ||||
| Tags | No tags attached. | ||||
| Theme | |||||
| Browser | All | ||||
| PHP Version | 5.3 | ||||
| Database Version | 5.1 | ||||
|
|
@developers: check from source code side, if such issue exist. |
|
|
Hello, Can you explain a bit more - are you installing fresh new shop using setup or updating existing shop? From which version you are updating? General setup should be used using default slq's from installation package, not custom ones. And what is "our modified codebase" as you mentioned in description? And maybe you now which templates causes triggering the retrieval of the additional field from oxuser? |
|
|
Reminder sent to: mbrotzeller Please check note to bug 0002194 |
|
|
From what i've figured, it's a vanilla 4.4.2 EE (the partially unencoded partner version, if that matters). Among the few modifications we had done at that time, i pinned the cause down to an additional field in the oxuser table. This field was referenced in one of the templates, and apparently that template modification changed how oxid retrieves the user object. Since i was doing a new install, i didn't include our sql mod before trying to log on as admin. I was trying: 1. unpack oxid 2. do setup 3. add custom modules 4. insert sql modifications into generated database but after 2., i could not log on to do 3. because i had to do 4. first. It's of course possible to switch 3 and 4, but i first had to find out the cause. |
|
|
Which template in basic directory was changed and was needed to be restored to make admin work again? I want to reproduce this case to check what should be done for fixing this issue so it would be nice to have more info how to reproduce it. |
|
|
Reminder sent to: mbrotzeller Please check note to bug 0002194 |
|
|
I rolled back the basic layout completely, there were changes in roughly 140 files, but i strongly think it was basic/tpl/details.tpl, since that is the only place where the database field is requested - the block in question looks like: [{ if $oxcmp_user }] [{ if ($oxcmp_user->oxuser__stpricegroup->value != 1) }] <span>UVP: [{ $product->getFormattedPrice($product->getRetailPrice()) }] [{ $currency->sign}]</span> [{/if}] [{ if ($oxcmp_user->oxuser__stpricegroup->value > 2) }] <span class="dinfo">MAP: [{ $product->getFormattedPrice($product->getStreetPrice()) }] [{ $currency->sign}]</span> [{ /if }] <big class="price pricerange" id="test_product_price">[{ $product->getFPrice(false) }] [{ $currency->sign}]</big> [{oxifcontent ident="oxdeliveryinfo" object="oCont"}] <sup class="dinfo">[{ oxmultilang ident="DETAILS_EXCL_MWST_PLUSSHIPPING" }][{ $oCont->getLink() }]</sup> [{/oxifcontent}] [{/if}] Although i dont quite grasp how that will hinder the start page and login process, probably the shop determines the query for the user object depending on all templates? |
|
|
Reminder sent to: mbrotzeller hi, It's still not very clear for us what changes affected such behavior. As we understood, you cannot login to eShop even after you do: "<...> 1. unpack oxid 2. do setup <...>" Means - you make fresh eShop installation from install packages (not Update on existing shop) and then you already cannot login to eShop? That would be very strange, because we didn't got any report that after fresh install eShop does not work (and we cannot reproduce it). Or we misunderstood something? Please explain in details at what moment you do the customization in DB or templates or source code, and what are the changes exactly. |
|
|
Since we can't keep the oxid shop separately from the code we develop for our customer, "do setup" includes the custom code of course. We had changed some parts of the basic layout, as described above. I think, the reference to $oxcmp_user->oxuser__stpricegroup->value above changes the standard SQL query that the shop uses to access the oxuser table, even for pages where the template in question is not used. |
|
|
Reminder sent to: mbrotzeller Hi, We have two ideas about this problem, both are related only to your custom changes in the eShop DB and source code: 1. If you run setup on already existing eShop (i.e. running setup again, not for the first time), possibole, that during login it tries to use some cached templates from /tmp dir, where request to some DB field (which not yet exists in the new eShop DB) is executed. In this case eShop logs you out immediately. 2. If you have some changes made in fresh shop installation, which includes described changes in the details.tpl AND there is a call for this template from Admin area, so it again - runs a request to DB for not (yet) existing DB field... and logs you out. In both cases - you should check your custom changes in the eShop. If any of these described cases not fits for you, please write about the problem to our support, to investigate your custom case more deeply. Best regards, |
