There's nothing wrong with having a user id in a URL. That's very RESTful (my account is distinct from your account, so they really ought to have different URLs), and can make a lot of sense in cases where users may delegate permission to manage each others' records. It's just trusting that user id without an authorization check that's idiotic.
To identify a logged in user and give the user access to their private account data, ONLY EVER use a unique and temporal random string. Nothing else. Ever.
Storing that random string in the URL may be done but is more insecure, because it will remain in the browser history. Not good if the user in on a public PC. Better store it in a cookie.
"Who am I", "which users/accounts may I access", and "which user/account do I want to access right now" are different questions, and it's only the latter that belongs in the URL. I agree that secrets in particular must not be exposed in the URL.
I personally prefer NOT to use Primary Keys in URLs for this exact reason. At the very least you can generate unique and difficult to guess keys that correspond to those IDs. A record ID (user id for example) has no use outside of database joins and therefore is useless in the public domain (url). As well, for public data (obviously not bank data) a data-based-key (song name, restaurant title, whatever) is far more useful in debugging and in logs.
Otherwise - you're absolutely right allowing access to protected records - via id, key, or whatever - should absolutely be checked against the authenticated session upon every request.
