We need to log each time sftp connector make a attempt to login into SFTP server.
We are listening on SFTP server using new or update sftp component and wants to log each time connector makes an attempt to login into SFTP server.
EDIT##
Is there a way to override the methods implemented for SFTP connection internally to achieve this request.
https://github.com/mulesoft/mule-sftp-connector
The SFTP connector doesn't notify the login attempts. If it can connect, log in, and detects new files, then it will trigger the flow execution. But I don't think that there is a login event that can be tracked.
We can track login attempts by enabling debug logs as per this documentation https://docs.mulesoft.com/mule-runtime/4.3/enable-verbose-logging
Related
So, I've set up my publishing with the exact same data as my filezilla client, I made sure I wrote the same credentials and it stablishes connection with it since it asks for the login credentials, but once I put the login info and click on accept, publishing cancels and gives me an error: "Website cannot be created 'sftp://blablabla.com/folder'. The server connection timed out.
Any ideas what could it be?
I have a relatively simple setup where I am using stomp over websockets to retrieve data from my backend to avoid resetting the session timeout. I am running into an issue that mostly happens when I restart my server. I reboot and I am properly prompted to login. After the login succeeds I am redirected. However instead of being redirected to the page I requested I am redirected to the stomp endpoint.
I suspect this is a timing issue where the stomp client is continuing to connect to the initial stomp http endpoint after the server starts up and is overwriting the request to the page with a request to the stomp endpoint.
Is there some way to make the stomp endpoint not a valid target for a login redirect?
This seems like it is really only an issue during dev since it really only occurs when the server is restarted. However, with my dev environment being deployed on push I dont want the testers to report this as an issue.
I have a web application which currently uses lighttpd with mod_auth and the htdigest method for authentication. I want to expand the web apps functionality to allow for 2FA. If I understand correctly, what happens for htdigest authentication is the following:
The browser requests a website from the server
The server responds with "authentication required"
The browser shows the user a window asking for username/password and sends this information to the server
The server serves the webpage
If I understand correctly, the server caches this auth info and automatically sends it for following requests.
Now, I want to add 2FA. I found out that I can use fastcgi to build a custom authorizer. Can I use this to do 2FA? How can I ask the browser to provide the user with a possibility to enter the OTP? It's no use to cache the OTP and send it with every request, so I guess I need to store a session token or something which the browser should send with every following request?
We have used Erlang/Cowboy to develop a simple chatting service based on WebSockets. Right now, We are using localhost:8080 to connect server.
I want to do user authentication, that will be done based on the URL parameter, and it will return user id or none for the connection.
How to do that?
Before the websocket exchange, you can ask a token to your application and use it with your websocket client.
I have had a look around to try to get some info on how to create a secure login and session on a phone gap app for ios. I'm trying to talk to an online server via an api. Can anyone give some tips or some starting point?
Thanks
You just want a secure login or secure interactions between your client and server?
If you want a secure login i would recommend you to transmit your username and password via. HTTPS to the server. On server-side you check it and if its ok you respond a session-token and a session cookie. For the rest of the interactions you only send your sessoin-cookie to identify yourself. When the user turns off the app, and starts it again you check your token expiraton date, if its still vaild you send your token to the server instead of username + password (HTTPS again) to get a new session-cookie.
With this way you dont have to transmit your user-data all the time and the user does not have to login every time he starts the app. You could also achieve this behavour if you store username and password on phone but thats very bad practice. If you want a totally secure connection between client and server (like for payments and stuff), you have to do it all with HTTPS.
Basically you use standard web-technologies. This way to handle this is called Token-Authentication.