weird login behaviour

[alpapan]

Hello

When using /apollo/auth/login, login with the admin user works as expected: fails with wrong password and redirects with correct password.

The redirection however is to this 404 of /apollo/grails/signIn:

Regardless, typing the URL then to /apollo, it asks for a new password using the modal window. This modal refuses to accept the correct password.

The log files are perplexing:

ERROR authenticator.UsernamePasswordAuthenticatorService  - Problem authenticating: org.apache.shiro.authc.IncorrectCredentialsException: Invalid password for user '[email protected]'
Oct 16 09:21:51 cory tomcat9[51339]: 2020-10-16 09:21:51,735 [catalina-exec-5] WARN  apollo.PermissionService  - Failed to authenticate user

I also tried with the second admin user hard coded in the config. Same results.

ERROR authenticator.UsernamePasswordAuthenticatorServi
ce  - Problem authenticating: org.apache.shiro.authc.IncorrectCredentialsException: Invalid password for user '[email protected]
'

When i put a fake user, it gives a user not found, so we know that Apollo finds the user. It's the password that's the issue.

I also tried without SSL.

I then tried using the REMOTE_USER approach that used to work.

    ProxyRequests Off
    ProxyPreserveHost On

##provided by genomearchitect:
    RequestHeader     set   Remote_User    "expr=%{REMOTE_USER}"

#    RewriteRule ^/apollo$ /apollo/ [R]
    ProxyPass /apollo/stomp/info http://cory.westernsydney.edu.au:8082/apollo/stomp/info
    ProxyPassReverse /apollo/stomp/info http://cory.westernsydney.edu.au:8082/apollo/stomp/info
    ProxyPass /apollo/stomp ws://cory.westernsydney.edu.au:8082/apollo/stomp
    ProxyPassReverse /stomp ws://cory.westernsydney.edu.au:8082/apollo/stomp
    ProxyPass /apollo http://cory.westernsydney.edu.au:8082/apollo
    ProxyPassReverse /apollo http://cory.westernsydney.edu.au:8082/apollo

    <Location "/apollo">
       AuthName "GPI Genome Curation"
       AuthType Basic
       AuthBasicProvider file
       AuthUserFile "/etc/apache2/passes/gpi"
       Require valid-user
#       RewriteEngine on
#       RewriteCond %{IS_SUBREQ} ^false$
#       RewriteCond %{LA-U:REMOTE_USER} (.+)
#       RewriteRule . - [E=RU:%1]
#       RequestHeader set REMOTE_USER %{RU}e
    </Location>

The Apache prompts appears but webapollo then requests another authentication, ie. remote user fails? I tried with the genomearchitect approach and then also my old approach that i knew worked (the commented out lines above)

The database hasn't changed.

I cannot use arrow because it won't work over Tomcat with apache SSL.

After 4-5 hours I'm at loss how to debug this....

a

[alpapan]

I should have said/realised this is due to me using SSL as per https://github.com/GMOD/Apollo/issues/2523.

Still i want to know why it doesn't work before i remove SSL (using tomcat SSL is a pain).

[nathandunn]

@alpapan I couldn't tell you without more network details and possibly some logging and configuration details.

That being said, I've used SSL with tomcat, but it was a long time ago. For whatever reason (maybe because of tools like letsencrypt / certbot, etc.), its just easier to apache or nginx to do the proxy: https://genomearchitect.readthedocs.io/en/latest/Configure.html?highlight=apache#apache-proxy

[nathandunn]

I would recommend closing this and then transferring all the notes to #2523 for clarity. If you get it working I can add it to a doc file.

[alpapan]

Hello

Sorry, it turns out that my setup is broken and it is not SSL. I just redid everything without SSL and i get the same issues.

Installing also a fresh arrow gave the same results:

arrow  users get_users
Traceback (most recent call last):
  File "/scratch/sysadmin/local_packages/anaconda3/2020.07/lib/python3.8/site-packages/arrow/decorators.py", line 16, in custom_exception
    return wrapped(*args, **kwargs)
  File "/scratch/sysadmin/local_packages/anaconda3/2020.07/lib/python3.8/site-packages/arrow/decorators.py", line 34, in list_output
    output = wrapped(*args, **kwargs)
  File "/scratch/sysadmin/local_packages/anaconda3/2020.07/lib/python3.8/site-packages/arrow/commands/users/get_users.py", line 22, in cli
    return ctx.gi.users.get_users(omit_empty_organisms=omit_empty_organisms)
  File "/scratch/sysadmin/local_packages/anaconda3/2020.07/lib/python3.8/site-packages/apollo/users/__init__.py", line 70, in get_users
    res = self.post('loadUsers', payload)
  File "/scratch/sysadmin/local_packages/anaconda3/2020.07/lib/python3.8/site-packages/apollo/client.py", line 82, in post
    raise Exception("Unexpected response from apollo %s: %s" %
Exception: Unexpected response from apollo 401:

Unexpected response from apollo 401:

NB: the username/passowrd is the one specified in the config.

Before I delete * from the database table, is there anything else I can do to find out where does apollo refuse the credential?

[nathandunn]

Do you have the server logs and your network post data?

Also, can you login normally?

[nathandunn]

Also, did you export everything else correctly with ARROW (is it using the correct credentials?):

export ARROW_GLOBAL_CONFIG_PATH=test-data/local-apollo3-arrow.yml

etc. etc.

[alpapan]

Yes arrow was setup: sorry if it wasn't clear - i merely updated my ubuntu installation and therefore tomcat and therefore webapollo.... it has been a week's worth of slog!

[alpapan]

I tried starting from scratch with an empty database and i get a host of errors that result in the application not being deployed....

Peculiarly, most of the tables are there.

ERROR context.GrailsContextLoaderListener  - Error i
nitializing Grails: Migration failed for change set changelog-2_0_2.groovy::1454711582784-1::cmdcolin (generated):
Oct 16 14:07:00 cory tomcat9[86018]:      Reason:
Oct 16 14:07:00 cory tomcat9[86018]:           changelog.groovy : ERROR: column "adsrc" does not exist
Oct 16 14:07:00 cory tomcat9[86018]:   Position: 205
Oct 16 14:07:00 cory tomcat9[86018]: :
Oct 16 14:07:00 cory tomcat9[86018]:           Caused By: Precondition Error
Oct 16 14:07:00 cory tomcat9[86018]: liquibase.exception.MigrationFailedException: Migration failed for change set changelog-2_0_2.gro
ovy::1454711582784-1::cmdcolin (generated):
Oct 16 14:07:00 cory tomcat9[86018]:      Reason:
Oct 16 14:07:00 cory tomcat9[86018]:           changelog.groovy : ERROR: column "adsrc" does not exist
Oct 16 14:07:00 cory tomcat9[86018]:   Position: 205
Oct 16 14:07:00 cory tomcat9[86018]: :
Oct 16 14:07:00 cory tomcat9[86018]:           Caused By: Precondition Error

[alpapan]

Successfully got it to run on the local deploy but there is just a connection problem when it is deployed via tomcat. However it is weird that /apollo/auth/login works fine but not /apollo/grails/signIn

[nathandunn]

@alpapan I removed the zoom link. Please shoot me an email (and/or post to the forum):

https://groups.google.com/a/lbl.gov/forum/#!forum/apollo

A couple of other ideas (depending on your usage):

1 - don't use postgresql > 12, use 9 or 10. Worst-case you can do think like add the column if need be. 2 - unless you need the new hot-ness of Ubuntu, I would use 16 or 18, but no gaurantees. 3 - be lazy and use docker? https://genomearchitect.readthedocs.io/en/latest/Docker.html 4 - If you are using AWS Marketplace, there are some options there. 5 - Use H2 instead of Postgreql, much easier to configure.

You might also try reading through this thread: https://groups.google.com/a/lbl.gov/g/apollo/c/Bg90mPCc94g

[nathandunn]

@alpapan I'm not sure what /apollo/grails/signin would point to. I'll await your discoveries in the morning. Good luck.

[alpapan]

Hello

I think the issue was that there is so much pain upgrading that I decide to go 2016->2020 so I don't have to do it in a couple of years again.

Unless i can migrate existing features, i wont' be able to switch to H2....

Having said that, the webapollo configuration is not the problem. Everything was up and running before the upgrade to the 2020 techstack.

I'd like to know why the table creation fails for a clean database and I'd also like to know why the passwords are not read properly.... but i don't know how! Will email you for next week.

[alpapan]

OK.... I'm 75% of the below but due to tiredness I may have made a mistake to:

TL;DR: the passwords stored in the old database were not compatible in the new installation for some reason.

I managed to overcome the login problem by getting a devel deploy of webapollo - I think - using the H2, logging in and then not logging out. I stopped that server and tried to go back to normal postgres.

The import of the old schema as the fresh installation was failing - and login on the browser, I was lazy (deploying jbrowse takes ages) so I then went to the tomcat directory and manually edited the database connection to the old database.

I checked the database grails_user and wrote down the old hash.

Then I updated my password via the web interface to be the same as it always was and lo behold... the database table entry was different for the 'password_hash' (same for the 'metadata' which includes the "INTERNAL_PASSWORD").

I then did the same thing for a remote user whose password i know and it had the same effect..................

now i have to explain it to my users, or not!

[alpapan]

p.s. remember that apollo/grails/auth/login.dispatch gave me a thumbs up when i previously used it with my password but the main apollo refused?

Now that I updated the password as above, apollo/grails/auth/login.dispatch fails (as expected if the salting was different)..... HOWEVER, if i go to the /apollo URL manually, then I've been magically logged in... exactly as expected.

f*kc me sideways as we say...

[nathandunn]

Hmm . .. a lot of variables here.

You should be testing against the web services: http://demo.genomearchitect.org/Apollo-staging/WebServices

I'm surprised the arrow won't work over SSL.

The initial authors (I just maintain it) who no doubt use arrow over SSL are here: https://gitter.im/galaxy-genome-annotation/Lobby

I think they use an apache or nginx proxy.

[nathandunn]

I think would have to use the web services to migrate the passwords because they should be stored securely in the database.