CODEWITHSUNDEEP
c#.netencodingencode
yajiv
yajiv

Reputation: 2941

How to encode string that give different encode character for same original string character?

We have e-commerce site in which have one item (mobile) with two types of category. One is 'good-mobiles' and other is 'bad-mobiles'.

We decide this by running some calculation on some parameter.

We have two database tables one store all good-mobiles (table name: gMobiles) and other store all bad-mobiles (table name: bMobiles). We add 'g' or 'b' before with some auto-incremented id and store it in respective tables.

So gMobiles contains all id which start with 'g' and bMobiles contains all id which start with 'b'. And we add this ids into url of details page.

Now problem is user can easily identify whether mobile is bad or good just by looking at urls or hovering on items on listing page in desktop.

To solve this problem we thought of using encoding (for example base64 encoding), but the problem with encoding is that in encoded string 'g' is replaced by some other characters and for all 'g' it always give same characters, so it will not solve our problem. 

Orig Text | Encoded Text
----------|-------------
    g1234 | ZDEyMz
    g1267 | ZDEyUS
    b3456 | YTEyMz
    b7654 | YTMyQs
    g7654 | ZDMyQs

We are not using encryption because encrypted string will be long (for 8 character input string it will give 40-50 character).

Is there any way which will give result string to be sort and one cannot able to find out whether mobile is good or bad just by looking at URLs.

Upvotes: 1

Views: 140

Answers (3)

Mark Seemann
Mark Seemann

Reputation: 233150

As lots of other people here have pointed out, the root cause is the database design, which you should change. If, for whatever reason, you can't do that, then you could consider obscuring the prefix a bit.

One option would be to say that all characters a-m represent g, and all the other other characters n-z represent b. This would mean that you could randomly decide to encode the ID g1234 as a1234, h1234, or l1234, but when you have to decode it, you'd know that they'd all three mean g1234.

Another rule could be to say that all vowels a,e,i,o,u,y represent g, and all consonants represent b. Again, this'd enable you to decode i1234 as g1234, but h1234 as b1234.

For really astute users of the site, this might still be detectable, but IME, most users don't even look at the address bar in order to see if their connection is secure or not...

Even so, you could invent your own algorithm. You only need it to be deterministic when you decode it.

But you should really change the database design.

Upvotes: 2

Rafalon
Rafalon

Reputation: 4515

As already mentioned, you should change the design of your table(s) so you have only one table with an additional column.

If you can't change this, another solution could be to pass the id in a POST request instead of a GET request, so it will not be displayed in the URL.

People could still figure out if your mobiles are good or bad, but it won't be obvious to most users.

Upvotes: 0

CodeCaster
CodeCaster

Reputation: 151594

Your problem stems from an incorrect database design. You can go all out and try to work around this choice, but the more sensible approach would be to revise that design.

Don't store entities in different tables just because they differ by a single attribute. What's next, a grMobiles for good red mobiles, and bbMobiles for bad black mobiles? And why prepend the prefix to the primary key anyway? It's already in the table name.

The solution is to save the "quality" attribute in a separate column in the same table. This will solve all your problems, and in the future even allow you to sell "mediocre" mobiles apart from good and bad ones.

Upvotes: 4

Related Questions