hide url value or pass variable in a different way?

Hi,

Using ColdBox 3.0...CF 8

I have some links on a page and when the user clicks one of the links,
they go to a customer detail page. Currently, the customer ID is
showing in the URL. Is there any way to prevent this besides
encrypting it?

I suppose I could query the database to see if the user that is
clicking the link should be able to actually do this based on who they
are, but I'm wondering if there is some other way to pass this value
so it doesn't appear in the URL at all. My concern is if a user
changes the customer Id value basically.

Right now I have this:

http://www.abc.com/index.cfm/customer/home/customerid/555541

I'd like this:

http://www.abc.com/index.cfm/customer/home

Any help appreciated on possible ways I could achieve this.

Thanks

Based upon the URI in your example, I am assuming this is the “home page” for a logged-in user. A “My Account” type of page, where only they are allowed to view their information, and they are only allowed to view their own information. If this is not the case, then please explain further. Otherwise, keep reading. :slight_smile:

Presumably you are storing the ID of the logged-in user in the session (or session facade, or whatever). When the user requests that page (/user/home), simply pull the ID from the session and display their information and only their information. No matter what they do with the URI, they will only see their stuff.

HTH

My situation is slightly different. Different reps at the company
have a screen where they can access these customer profiles. Each rep
should only be able to view the customers assigned to them. So when
the rep logs in, he/she see a list of links like:

link 1: http://www.abc.com/index.cfm/customer/home/customerid/555541
link 2: http://www.abc.com/index.cfm/customer/home/customerid/348541
link 3: http://www.abc.com/index.cfm/customer/home/customerid/11141
link 4: http://www.abc.com/index.cfm/customer/home/customerid/84248

I want to prevent a given rep from changing the url value (55541), to
something else with the hope to see something they shouldn't.

I'm thinking I may have to query the db or something to verify using
the logged in user id and the id of the record they are trying to
access.. ...

Open to any thoughts...

I think that is a fantastic idea. :slight_smile:

What you could do is query the db when the rep first logs in. Grab a list (record set) of the customers assigned to them, and then cache that query. This way the lookup to the db is done only once per session.

I’m a fan of hack-ish solutions, so here’s something you might try…

Instead of passing the actual customerid from the database, pass a relative ID. What I mean is, if the user can view these four links:

link 1: http://www.abc.com/index.cfm/customer/home/customerid/555541
link 2: http://www.abc.com/index.cfm/customer/home/customerid/348541
link 3: http://www.abc.com/index.cfm/customer/home/customerid/11141
link 4: http://www.abc.com/index.cfm/customer/home/customerid/84248

Instead give them:

link 1: http://www.abc.com/index.cfm/customer/home/customerid/1
link 2: http://www.abc.com/index.cfm/customer/home/customerid/2
link 3: http://www.abc.com/index.cfm/customer/home/customerid/3
link 4: http://www.abc.com/index.cfm/customer/home/customerid/4

The new relative customerid just represents which actual record to use when the page is called.

So, when the page that displays the record is loaded, simply use the relative ID (1 - 4) to choose the corresponding row from the records available to the user. If the user sends in customerid 3, then get the third row from the query of customers belonging to the user.

Every user would have:
customerid/1
customerid/2
etc

If a user has 50 available customers, they have customerid/1 through customerid/50, the ACTUAL customerid wouldn’t matter at all.

Now, of course, new records could get inserted or deleted between when the list loads and when the link to view the customer is actually clicked, which could result in a mismatch of the index number (the relative customerid) to the list of available customers, which would result in the wrong information possibly being displayed. The contingency for this is to:

1.) cache the query for a period of time that matches the longest possible time the list can be displayed (not required if you do steps 2, but will still help)

2.) create an array or simple list in each user’s session that holds a list of their
customerids, so: 555541,348541,11141,84248. This way, when you pass in the relative customerid (1,2,3,etc) you can simply get the element from the list at that index and display it. The clever part about this is that if any records are added or deleted, that’s ok. The list is in the session and contains only the exact list that corresponds to the list that was displayed in the browser. The list in the session won’t be changed until the next call to the list page.

If the number of records is large, simply keep the query stored in the session instead of an array or list, and use the same method of using the relative customerid to get that corresponding row from the query stored in the session (which gets updated the next time the list is loaded, and would then reflect new insertions and deletions).

Hope this helps! (Even just for fun if you don’t want to use this kind of thing in production)

For similar situations I have hashed the customer id and persisted in the db. I then pass the hash around. Its security through obscurity, but, for internal people already vetted it should probably be a decent check. When a new customer is added simply hash their PK since it should never change.

Using a simple createUUID() works for this purpose too, you can reference them via a non-sequential identifier.

Thanks for the responses all good stuff. I may encrypt the URL value
or just make sure that I check the db to make sure they have
permission to do this using the user's userid.

Would’nt it be better to just assign a user customer’s he/she has access to?
Then have a security interceptor verify that the incoming customer ID is assigned to the user, else kick them out.