Psychoanalytic-Electronic-Publishing / PaDS

Psychoanalysts Database System (PaDS) is a user database and authorization server with an API to manage and authenticate users for the PEP User Interface client and OPAS Document server.
0 stars 0 forks source link

IP Authenticate requests #12

Closed jwoosnam closed 3 years ago

jwoosnam commented 3 years ago

I have included Alan in this issue but I think it mainly concerns Neil. The server with the IP address 3.234.215.231 is calling IP authenticate every second or so, 24 hours a day.

Is this necessary?

The session ID created never seems to be used for anything else and the number of records in my logs, will at some point become excessive, makes it difficult to track other things we are investigating.

nrshapiro commented 3 years ago

@jwoosnam @adistasio @lhorne-gavant

The server calls IP authenticate to get a sessionID whenever a call is made to it without a sessionid, since it needs a session id to ask you about the session when they do a search. But if someone calls one of the non-search functions, like Status, it will request a session_id just for that call.

It does seem that someone is calling it repeatedly -- but they are calling one of the Endpoints that isn't logged, like /v2/Session/Status. Sort of a heartbeat timer?

If it were just the server doing it, you'd also be getting it from my PC, which is running the server continuously as well. It is not.

Is the client polling the server, or does Leyla have Cloudwatch perhaps polling?

I noticed something funny in the client last night. I tried to log out of my session, and I got 10-20 popup message errors saying something about illegal login in a row, like it was repeatedly trying to log-in -- but I don't know with what credentials. Then I got the "server error" message that I have reported with the client, requiring me to clear my cookies.

nrshapiro commented 3 years ago

@jwoosnam
James, can you create a new endpoint to simply request a session id? That's probably better than using the side effect of the IP authenticate (which I'm using, even though my IP isn't going to authenticate). It would be then easier to trace any issues as well.

Something like:

/PEPSecure/api/v1/Authenticate/StartSession or just /PEPSecure/api/v1/Authenticate/Session

jwoosnam commented 3 years ago

@adistasio, I thought the first thing the client did was to do an IP Authenticate to get a session ID and potentially a valid logon. How is OPAS getting requests from the client without a sessionId?

@nrshapiro If there is no session ID then the user can't be logged on, so why do you need to contact PaDS. They are not authenticated and therefore have no access.

nrshapiro commented 3 years ago

@jwoosnam Because the server doesn't require that the client is logged on for most things. And it's stateless. But it still needs to log activity, so it needs a session id, since that's the key for the logs and many other things.

And there's no guarantee that someone else isn't calling the server besides the Gavant client. It's an open access server.

In fact--that brings up a great point--it might be PEP-Easy calling the server. I haven't edited it for the new code! It does call Token a lot. I'll have to check that right away.

jwoosnam commented 3 years ago

@nrshapiro Using the Authenticate/IP end point is not a problem for the rare number of times your server won't be contacted from the client. I was just concerned it was happening so often for no apparatus reason.

nrshapiro commented 3 years ago

@adistasio @jwoosnam

Looking at the cloudwatch logs, someone is calling /v2/Session/Status repeatedly. It's not PEP-Easy. (I've disabled it--or tried to--it still seems to be cached--anyway for now until I can update it for the new login methods).

adistasio commented 3 years ago

@nrshapiro @jwoosnam

Yes so beanstalk is pinging that endpoint to ensure the application is running. This is what tells beanstalk if the application dies and needs to restart it. I believe this endpoint should not require a session-id and not ask for one. Beanstalk will never have a session and we don't need this end point for tracking purposes.

nrshapiro commented 3 years ago

@adistasio @jwoosnam

Well that endpoint offers more information about the setup to the admin, so it needed to use a session_id to see whether the user was an admin.

Do you want to see if the server is alive, or do you care about solr/rds too?

If only the server, I can give you a different endpoint to check if it's alive. That one calls Solr and RDS each to check their status. If you don't care about those, it's a waste.

v2/Api/Status

I can make that endpoint real short and sweet. If you want to use an API key so no-one else calls it we can do that easily too.

adistasio commented 3 years ago

@nrshapiro Yes we just need to see if the server is alive, we don't care about solr/rds with this check. If the server isn't alive beanstalk would cycle a new one. Let me know when /v2/Api/Status is ready for us and we can swap beanstalk to look at that.

nrshapiro commented 3 years ago

@adistasio @lhorne-gavant

I just pushed it to stage-api...should be there in minutes.

Call is as described /v2/Api/Status

Documentation (no params) on http://stage-api.pep-web.rocks/docs

nrshapiro commented 3 years ago

@adistasio @lhorne-gavant @jwoosnam

Ok, I figured you folks may have gone home, and watching the logs, it was creating so many endpoints. So I TEMPORARILY mapped both endpoints to the code in v2/Api/Status. Let me know when you fix the heartbeat timer and then I'll reattach the /v2/Session/Status endpoint back to the regular code.

Sorry it took me so long--it took 10 minutes to add the new endpoint but the rest of the day to finish what I had already started working on in the server and to then retest.

lhorne-gavant commented 3 years ago

@nrshapiro Staging is now using the new endpoint.

jwoosnam commented 3 years ago

Thanks to all the number of Authenticate IP calls has reduced dramatically.