PDA

View Full Version : problem with admin login-max1.5-help



whazzy
10-15-2003, 09:31 AM
Hi all,
I have succesfully installed the ms2-max 1.5.But when i want to login to admin,user name:admin@localhost.com p/w: admin, it does not do anything...It just refreshes the page and I am back to the login page again...
Any possible suggestions to get past the login page in admin?
Thanks

whazzy
10-15-2003, 09:51 AM
Got it fixed....I changed the define_store_session in configure.php(both in catalog/includes/configure.php and admin/includes/configure.php) to point to 'mysql' instead of the default session handler..don't remember doing it on the previous installation tho...
Regards
Whazzy

bonkfilms
11-12-2003, 10:03 AM
I have the same problem , how you change configure.php

proton318
11-13-2003, 10:51 AM
I have modified the configure.php files in both the admin and catalog sections and it does not fix my problem. In fact, when I make the changes, it amplifies my problem.

I used to be able to request a new password for my UID's from the login page. After making the alterations, I still get looped back, but it no longer lets me request a new password. I had to remove the edits and go back to the originals. Unfortunately, they still don't work.

So, I'm back to square one. I am still unable to login to the admin section. I have another post about this problem at the following thread that gives more/similar information.

http://www.oscdox.com/index.php?name=PNphpBB2&file=viewtopic&t=1507

Can anyone please help??

bonkfilms
11-13-2003, 12:18 PM
Please check if you have sessions open or close and safe mode on or off in your PHP server.

Anonymous
11-13-2003, 01:07 PM
Safe mode = off
Sessions (cookies) = on

:shock:

I used to be able to login to the admin system without a problem. I had this project on the back burner for a couple of months and now that I am trying to get it moving again I can't access they admin section.

Very Frustrating!! Could it be an irritating software bug or just a simple setting problem??

On my end and also on the hosting provider, there have been no changes that would cause this problem (like server software upgrades or modification to any PHP files). I do have my own SSL (so ther is no sharing conflicts) and below is a "cut and past" directly from the php.ini file being used. Maybe this can offer some insight?!

It's long and detailed (just a warning) ... here goes ...


[Session]
; Handler used to store/retrieve data.
session.save_handler = files

; Argument passed to save_handler. In the case of files, this is the path
; where data files are stored. Note: Windows users have to change this
; variable in order to use PHP's session functions.
; As of PHP 4.0.1, you can define the path as:
; session.save_path = "N;/path"
; where N is an integer. Instead of storing all the session files in
; /path, what this will do is use subdirectories N-levels deep, and
; store the session data in those directories. This is useful if you
; or your OS have problems with lots of files in one directory, and is
; a more efficient layout for servers that handle lots of sessions.
; NOTE 1: PHP will not create this directory structure automatically.
; You can use the script in the ext/session dir for that purpose.
; NOTE 2: See the section on garbage collection below if you choose to
; use subdirectories for session storage
session.save_path = /tmp

; Whether to use cookies.
session.use_cookies = 1

; This option enables administrators to make their users invulnerable to
; attacks which involve passing session ids in URLs; defaults to 0.
; session.use_only_cookies = 1

; Name of the session (used as cookie name).
session.name = PHPSESSID

; Initialize session on request startup.
session.auto_start = 0

; Lifetime in seconds of cookie or, if 0, until browser is restarted.
session.cookie_lifetime = 0

; The path for which the cookie is valid.
session.cookie_path = /

; The domain for which the cookie is valid.
session.cookie_domain =

; Handler used to serialize data. php is the standard serializer of PHP.
session.serialize_handler = php

; Define the probability that the 'garbage collection' process is started
; on every session initialization.
; The probability is calculated by using gc_probability/gc_dividend,
; e.g. 1/100 means 1%.

session.gc_probability = 1
session.gc_dividend = 100

; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
; WARNING: Your filesystem must store access times. Windows FAT does
; not. So, see session_set_save_handler() and write your own
; session handler with a different mechanism for cleaning up sessions.
session.gc_maxlifetime = 1440

; NOTE: If you are using the subdirectory option for storing session files
; (see session.save_path above), then garbage collection does *not*
; happen automatically. You will need to do your own garbage
; collection through a shell script, cron entry, or some other method.
; For example, the following script would is the equivalent of
; setting session.gc_maxlifetime to 1440 (1440 seconds = 24 minutes):
; cd /path/to/sessions; find -cmin +24 | xargs rm

; PHP 4.2 and less have an undocumented feature/bug that allows you to
; to initialize a session variable in the global scope, albeit register_globals
; is disabled. PHP 4.3 and later will warn you, if this feature is used.
; You can disable the feature and the warning seperately. At this time,
; the warning is only displayed, if bug_compat_42 is enabled.

session.bug_compat_42 = 1
session.bug_compat_warn = 1

; Check HTTP Referer to invalidate externally stored URLs containing ids.
; HTTP_REFERER has to contain this substring for the session to be
; considered as valid.
session.referer_check =

; How many bytes to read from the file.
session.entropy_length = 0

; Specified here to create the session id.
session.entropy_file =

;session.entropy_length = 16

;session.entropy_file = /dev/urandom

; Set to {nocache,private,public,} to determine HTTP caching aspects
; or leave this empty to avoid sending anti-caching headers.
session.cache_limiter = nocache

; Document expires after n minutes.
session.cache_expire = 180

; trans sid support is disabled by default.
; Use of trans sid may risk your users security.
; Use this option with caution.
; - User may send URL contains active session ID
; to other person via. email/irc/etc.
; - URL that contains active session ID may be stored
; in publically accessible computer.
; - User may access your site with the same session ID
; always using URL stored in browser's history or bookmarks.
session.use_trans_sid = 0

; The URL rewriter will look for URLs in a defined set of HTML tags.
; form/fieldset are special; if you include them here, the rewriter will
; add a hidden <input> field with the info which is otherwise appended
; to URLs. If you want XHTML conformity, remove the form entry.
; Note that all valid entries require a "=", even if no value follows.
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldse t="

I have seen a couple of other posts about this, but no solid fix ... is there a resolution??

Again, thanks in advance!!

proton318
11-13-2003, 01:10 PM
Sorry, that last post (Guest) was mine ... :oops:

Again, there is additional information at;

http://www.oscdox.com/index.php?name=PNphpBB2&file=viewtopic&t=1507

Thanks!

michael_s
11-13-2003, 03:37 PM
There is no fix because it is a server issue, not and osc one. The causes can be about a dozen things.

It can be incorrect perms on the sessions dir, non-existant session dir, wrong ownership on session dir, incorrect http/https path, changed browser settings, or any combo of these.

I have never had this problem on any max site that I have installed (200+) so I doubt it is a problem with the admin. If it was working, but now it is not, chances are you changed something to break it, things dont break on their own.

My best advice is to backtrack, or reinstall the admin files from scratch...