Jump to content
McKay Development

3urobeat

Member
  • Posts

    22
  • Joined

  • Last visited

Contact Methods

  • Website URL
    https://github.com/HerrEurobeat

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

3urobeat's Achievements

  1. I implemented a function to solve this issue and opened a pull request: https://github.com/DoctorMcKay/node-steam-user/pull/444
  2. Hey! I'm spawning multiple (possibly a few hundred) SteamUser objects and this can cause my application to crash as I'm reaching the nodejs process mem limit. I have therefore decided to investigate (instead of simply raising the limit, but I did do that as well): The picsCache seems to be the worst offender right now (~4MB per SteamUser instance) and as I only need it for a few seconds after 'ownershipCached' I'm trying to clear it. I have set 'changelistUpdateInterval' to 0 so it won't get refreshed and I'm deleting the 'picsCache' properties like this: this.user.picsCache.apps = {}; this.user.picsCache.packages = {}; After taking a few Memory Snapshots I saw that this seems to work, however the Garbage Collector is not taking action as there seems to be another reference to this object at 'apps.js:266' in an '_jobs' object. Sometimes this reference gets removed after some time. Do you have an idea how I could get rid of this reference? ...or would you be interested in providing a function in the lib to clear this cache in a more official way? I think this could be a useful feature. If you have any other ideas how I could reduce the memory usage, please let me know! The protobufs (in this case of steam-session and not steam-user) for example are at the top of my 'strings' list (probably nothing that can be done there). Thanks! (One more thing while you are here, could you please re-review my steamcommunity sharedfiles PR? I made the changes you requested shortly after. The disabled primaryGroup profile setting also works btw. Sorry for bothering!) Versions used: OS kernel: 6.3.8-arch1-1 Node: v20.3.1 (but the same behavior appears on other versions as well) steam-user: 4.28.6 argv used for node: --max-old-space-size=2048 --optimize-for-size
  3. Oops, yeah you're right, even though I had the latest version installed, a simple 'npm update' fixed it. Sorry for bothering you ^^
  4. Hey! I am unable to use the same proxies I use for steam-user with steam-session. My HTTP proxies do not use port 80 and as soon as I'm creating a LoginSession object using new SteamSession.LoginSession(SteamSession.EAuthTokenPlatformType.SteamClient, { httpProxy: "http://user:pass@ip:port" }) and calling startWithCredentials() this error fires: Error: connect ECONNREFUSED ::1:80 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) { errno: -111, code: 'ECONNREFUSED', syscall: 'connect', address: '::1', port: 80, proxyConnecting: true } Is this intended behavior? The same proxy works without any problems with steam-user and steamcommunity. If I provide a socks proxy this problem does not occur. Sorry if I missed something in the documentation. Edit - Versions: node: 18.16.0 (but the same behavior appears on 19.something) steam-session: 1.2.2 OS: Arch Linux 6.3.3-arch1-1 steam-user (for comparison): 4.28.4
  5. Hey! As you maybe have already seen, I opened a pull request to add full sharedfiles (Screenshots, Artworks & Guides) support to your steamcommunity library. I'm currently working on adding sharedfiles support to my Steam Comment Service Bot and I'm trying to detect whether a provided ID is of type individual, clan or sharedfile. For the first two I can use your SteamID lib, which is sadly not the case for the last one. I'm therefore asking if you'd have an idea about how a detection could be implemented. I know this is technically outside the scope of the SteamID library as not even Steam themselves recognize sharedfiles as a type of SteamID, so I wouldn't expect you to accept such an addition to the library itself, but I'd like to add such a support to a fork at least. The reason why I'm writing this post in the first place is because (1.) I don't really understand how your detection of the 64bit SteamID types work and if it could be modified to work for sharedfile IDs as well: this.type = Number((num >> 52n) & 0xFn); ...and (2.) because I'd like to ask if you know anything else that might be interesting about sharedfile IDs. There is sadly little to none to find about them on the internet. These for example are valid sharedfile IDs: 2966606880, 1865848847, 1934792223 Afaik these don't have to have this length and can be shorter and maybe also even longer. Neither length nor the first digit can be an indication that this is a sharedfile ID and not something else. They are provided as a query parameter to view the page: steamcommunity.com/sharedfiles/filedetails/?id=<id> I could of course ping the whole URL if SteamID doesn't recognize the ID as one of the other types and see if a sharedfile with that ID exists, but I'd like to come up with a solution that doesn't require a request, if possible. I'm however pretty much out of ideas on how I could realize this with number-magic. That's it, thanks for reading. I doubt that you can help me much but I thought I'd be stupid if I don't at least try to ask you for any idea. Have a nice day Edit: I think I'm just giving up, I see no possible way of validating the ID if it can be pretty much arbitrary. There is absolutely zero information about these IDs to find. Making a http request in the SteamID constructor when a 64bit int was provided but Type is INVALID is awful as well because it would lead to an async constructor. I think I need to implement an http request when Type is INVALID in my application rather than in the library. Sorry for wasting your time.
  6. Alright, thank you very much for the response. Sad to see the 200 days limit but I guess it makes sense from Valve's perspective. Two more things I just stumbled about: The steam-session lib does not support proxies right? I always used proxies for steam-user and steam-community when using many accounts to avoid cooldowns (not specifically for the logins itself but I always figured it could help there as well as Steam will surely block lots of logins from the same IP). Could I now run into errors when trying to create many new sessions in a short period of time? Or does Steam only care about the steam-user logOn itself with the refreshToken? You state in the steam-user readme "If you attempt to log on using a refresh token that isn't valid for use with client logins, the app will crash with a relevant error message.". Since this is pretty vague I skimmed through the EResult enums. The only steam-user error event eresults on which I should invalidate the token used and get a new session would probably be InvalidLoginAuthCode and ExpiredLoginAuthCode I guess? Or am I missing something?
  7. Hey, I'm implementing the new `steam-session` login flow at the moment and I'm storing the retrieved `refreshToken` in a database so the user doesn't need to input a Steam Guard code on every start. If I understand correctly `steam-user` did basically the same thing (I do not understand the difference between access_token and refreshToken yet) by storing an access token in a sentry file. This token seems to be available at `client._logOnDetails.access_token` when logged in. So my question: Is it possible to retrieve this token before being logged in so that I can transfer it to my new `steam-session` database? Otherwise everyone updating to the new version of my bot would need to type in the guard codes again for every account (which would also cause downtime since the automatic updater would update, restart the bot and then get stuck when trying to log in again with the new system as it would wait for a guard code input). My compatibility feature runs after the update but before logging in so I don't have access to the old steam-user client object. Also two more things I'm a little unsure about this new system, which I would like a second opinion on: Should I encrypt my refreshToken database somehow? It looks like you did that with the sentry .bin files but how could I go about that myself? The login data supplied by the user is unencrypted anyway so I'm not sure if it would even make a difference. Is there any possibility that a refreshToken can be "renewed" (while still valid) without asking for a steam guard code or is the user forced to go through the steam guard code process at least every 200 days for each account? I'm asking because this would get really annoying when using my bot with many accounts. Thank you in advance!
  8. Thanks for the quick response! Sure, these versions were used the last time the error occurred (2022-07-04): OS: Arch Linux 5.15.55-1-lts My bot: BETA 2.12 b8 (Repo at the point of commit) node.js: 16.13.1 steam-user: 4.24.3 steam-crypto: 1.2.0 steamcommunity: 3.44.1 One more interesting thing I just noticed in my log: There was one time (out of 5 since 2022-05-22) where an account recieved a second different error as well and actually managed to relog fine. (So 4 times since 2022-05-22 the behaviour above happend, one time this happened) Log excerpt from connection loss until webSession event: [2022-05-24 15:37:51 | INFO] [Bot 32] Lost connection to Steam. Reason: Error: Encrypted message authentication failed [2022-05-24 15:37:51 | INFO] [Bot 32] Initiating a relog in 30 seconds. [ERROR] Uncaught Exception Error! Reason: RangeError: Illegal range: 0 <= 8 <= 1208313696 <= 148 at ByteBuffer.module.exports.ByteBufferPrototype.slice (/steam-comment-service-bot/node_modules/bytebuffer/dist/bytebuffer-node.js:2764:23) at SteamUser._handleNetMessage (/steam-comment-service-bot/node_modules/steam-user/components/03-messages.js:529:81) at TCPConnection._readMessage (/steam-comment-service-bot/node_modules/steam-user/components/connection_protocols/tcp.js:194:13) at Socket.emit (node:events:390:28) at emitReadable_ (node:internal/streams/readable:578:12) at onEofChunk (node:internal/streams/readable:556:5) at readableAddChunk (node:internal/streams/readable:269:5) at Socket.Readable.push (node:internal/streams/readable:228:10) at TCP.onStreamRead (node:internal/stream_base_commons:249:12) [2022-05-24 15:37:51 | WARN] If the bot doesn't work correctly anymore after this error then please restart it! [ERROR] Uncaught Exception Error! Reason: Error: error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length at CipherBase.final (<anonymous>) at Decipheriv._flush (node:internal/crypto/cipher:160:29) at Decipheriv.final [as _final] (node:internal/streams/transform:112:25) at callFinal (node:internal/streams/writable:694:27) at prefinish (node:internal/streams/writable:719:7) at finishMaybe (node:internal/streams/writable:729:5) at Decipheriv.Writable.end (node:internal/streams/writable:631:5) at Object.exports.symmetricDecrypt (/steam-comment-service-bot/node_modules/@doctormckay/steam-crypto/index.js:80:10) at TCPConnection._readMessage (/steam-comment-service-bot/node_modules/steam-user/components/connection_protocols/tcp.js:185:27) at Socket.emit (node:events:390:28) [2022-05-24 15:37:51 | WARN] If the bot doesn't work correctly anymore after this error then please restart it! [2022-05-24 15:38:21 | INFO] [Bot 32] Queueing for a relog. 0 other accounts are waiting... [2022-05-24 15:38:22 | INFO] [Bot 32] It is now my turn. Waiting 2.5 seconds before attempting to relog... [2022-05-24 15:38:25 | INFO] [Bot 32] Trying to relog with proxy 5... [2022-05-24 15:38:26 | INFO] [Bot 32] Account logged in! Waiting for websession... [2022-05-24 15:38:27 | INFO] [Bot 32] Got websession and set cookies. [2022-05-24 15:38:27 | INFO] [Bot 32] Relog successful. [2022-05-24 15:38:27 | INFO] [Bot 32] Accepting offline friend & group invites... Maybe this helps in some way narrowing down the issue. I'll try and force the protocol to WebSocket in the meantime as you suggested, however it's hard to see if it'll make a difference as the behaviour only occurrs roughly once a month.
  9. Hey, I'm running into a weird situation and don't know where to go from here. It happens roughly once a month and causes my bot to "freeze" as the account gets stuck in the relog queue and prevents all other accounts from relogging. The issue: One of my accounts recieves the error event "Encrypted message authentication failed" (autoRelogin is false!) after being online already for quite some time (so the error doesn't happen on login) and an Unhandled Rejection "error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length". Well whatever, I'm just going to push the account to my relog queue system which should get the account back up after waiting 30 seconds. But now weird things happen: I call bot.logOff() just to be sure, wait a few more seconds, then call bot.logOn() again but another Unhandled Rejection fires: "Already logged on, cannot log on again". Firstly, shouldn't that error trigger the error event instead of an unhandledRejection? But mainly - how is based on your comment here as well as on the check in the code the bot.steamID object defined when I specifically called bot.logOff()? (or does logOff() not handle that and I need to do something else?) I'm confused. Maybe the lib is unable to handle the logOff call after that error? Do you have an idea where to go from here? This problem is probably hard to troubleshoot as I don't know how one would replicate the error. I am using proxies maybe that contributes to the error. (Maybe) relevant stuff: Log: [2022-07-04 14:40:38 | INFO] [Bot 13] Lost connection to Steam. Reason: Error: Encrypted message authentication failed [2022-07-04 14:40:38 | INFO] [Bot 13] Initiating a relog in 30 seconds. [ERROR] Uncaught Exception Error! Reason: Error: error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length at CipherBase.final (<anonymous>) at Decipheriv._flush (node:internal/crypto/cipher:160:29) at Decipheriv.final [as _final] (node:internal/streams/transform:112:25) at callFinal (node:internal/streams/writable:694:27) at prefinish (node:internal/streams/writable:719:7) at finishMaybe (node:internal/streams/writable:729:5) at Decipheriv.Writable.end (node:internal/streams/writable:631:5) at Object.exports.symmetricDecrypt (/steam-comment-service-bot/node_modules/@doctormckay/steam-crypto/index.js:80:10) at TCPConnection._readMessage (/steam-comment-service-bot/node_modules/steam-user/components/connection_protocols/tcp.js:185:27) at Socket.emit (node:events:390:28) [2022-07-04 14:40:38 | WARN] If the bot doesn't work correctly anymore after this error then please restart it! [2022-07-04 14:41:08 | INFO] [Bot 13] Queueing for a relog. 0 other accounts are waiting... [2022-07-04 14:41:09 | INFO] [Bot 13] It is now my turn. Waiting 2.5 seconds before attempting to relog... [2022-07-04 14:41:11 | INFO] [Bot 13] Trying to relog with proxy 2... [ERROR] Unhandled Rejection Error! Reason: Error: Already logged on, cannot log on again at /steam-comment-service-bot/node_modules/steam-user/components/08-logon.js:28:11 at processTicksAndRejections (node:internal/process/task_queues:78:11) at runNextTicks (node:internal/process/task_queues:65:3) at processTimers (node:internal/timers:497:9) My error event handler My relog system (Is there something to improve? Waiting, doing logOff(), waiting and then logOn() should be a clean relog, right?)
  10. I have updated steam-user to v4.19.7 and downgraded my bot to 2.10.4 in order to test relogging without my relog queue update. CPU usage looks fine again (spikes up to ~40% but is mostly at ~25%) during startup so thats good. During login (regular login, before causing a connection reset) there are a lot of WebSocket timed out debug messages, not sure if those were present before too. After causing a connection reset it took 15 minutes again before they realized they had lost connection. For some odd reason I recieved multiple Unhandled Rejection "Already logged on, cannot log on again" errors (I sadly can't track down from which account they come but I guess from one of the failed accs(?)), the bot was definitely running only once and the accounts were not logged in somewhere else. This never happened before. I have attached the full log below. It contains all messages starting with the first login and ending ~10 minutes after the accounts realized they had lost connection. The connection reset was at 12:29:10. 4/10 accounts did fail to log back on (Main (Bot 0), Bot 7, Bot 8 and Bot 9). I have also attached a filtered log that only contains messages from the main account (Bot 0). filtered.txt steamtestoutput.txt
  11. Yes I am indeed using a Raspberry Pi (3B) for hosting the bot. I haven't tested if the original issue of this post is also present on my main machine. I have just updated to v4.19.6 and I see you implemented queueing for multi msg processing because it absolutely obliterates the log (you should maybe think of another way of logging "Enqueued incoming message" because I just got 1970 lines of that message in one second). However I am sadly not able to test/use the version because logging in now uses 85% CPU which results in my bot not being able to log in all accounts (maybe but I would need to wait 10+ minutes instead of 40 seconds). My desktop machine has no problem with the update. (Ryzen 5 2600) I have just rolled back to v4.19.5 and logging in works fine again with just 25% CPU usage. Last few lines before only printing "[2021-05-11 14:55:49] debug: Enqueued incoming message; queue size is now 5" 2k times per second (seems like it got stuck trying to process a msg):
  12. Alright, I made an update containing a custom relog function which queues each account loosing connection and relogs each one after another. I tested it yesterday and overnight and all accounts survived the connection reset of my router. This should confirm that the accounts indeed failed to relog because of too many login requests in a short timespan. I have yet to test how my implementation behaves when Steam is down and the bot can't reconnect on the first try (but it should retry through the error event until sucessful). GitHub commit (if you are interested): https://github.com/HerrEurobeat/steam-comment-service-bot/commit/fafad59 Another thought regarding the 15 minutes delay before emitting disconnected: I found this answer which you made in a post from 2017. Is this still relevant and might be the reason for this behaviour? I haven't tested my bot on Windows since a few months now after fully switching to Linux in the beginning of this year and therefore can't compare right now. Log to prove that the accounts still lost connection very close to each other:
×
×
  • Create New...