When I send a url link to a user to view/edit a record in AwareIM, I want to obfuscate the link so the user cannot make out the content of the url string.
There are some reasons for this, one being so an inquisitive client (user) cannot second guess other records and snoop around the system object.
(This is quite possible, all one has to do is change the ID in the url etc etc)
Also its a good way to hide the password (although it can be decoded with some effort but at least its better than an exposed password)
I understand this is possible by using BASE64 method. I have had a dialogue with support and this is possible but will cost for he implementation
I am looking for some volunteers to pitch in for this feature- I am sure this has universal appeal - Any takers ?
Obfuscation of url LINKS - Pitch in ?
Obf. links
Sounds interesting and like good feature. What is the cost/estimate for this work?
Henrik (V8 Developer Ed. - Windows)
Can you provide some more details around how this would work - so I can understand what you're proposing? (which I think would be useful for us)
For example are you talking about, where you send someone a link to log into an aware app (usually as a guest) and do a firstcommand, currently you would use something like this:
http://myIP:8080/AwareIM/logonOp.aw?dom ... tr2=Value2...
Are you proposing this feature would make it look like this:
http://myIP:8080/AwareIM/logonOp.aw?dom ... udh90sdjsi
Or something similar?
For example are you talking about, where you send someone a link to log into an aware app (usually as a guest) and do a firstcommand, currently you would use something like this:
http://myIP:8080/AwareIM/logonOp.aw?dom ... tr2=Value2...
Are you proposing this feature would make it look like this:
http://myIP:8080/AwareIM/logonOp.aw?dom ... udh90sdjsi
Or something similar?
Rod. Aware 8.6 (latest build), Developer Edition, on OS Linux (Ubuntu) using GUI hosted on AWS EC2, MYSQL on AWS RDS
Similar to the Facebook login, Twitter login, Gmail integration...
https://bitly.com/ URL shortening also offers API and can be integrated with AIM for offer this service.
There are others as well like http://goo.gl.
Wonder if this is something that might be useful.
Cheers
https://bitly.com/ URL shortening also offers API and can be integrated with AIM for offer this service.
There are others as well like http://goo.gl.
Wonder if this is something that might be useful.
Cheers
RLJB
yes in your Object there would be a Base64 translation equivalent to the url link. You can get more info here http://www.base64encode.org/
hpl123
The bitly.com wont work as the URL link is changing all the time. Each email sent has a unique ID in the Url link
yes in your Object there would be a Base64 translation equivalent to the url link. You can get more info here http://www.base64encode.org/
hpl123
The bitly.com wont work as the URL link is changing all the time. Each email sent has a unique ID in the Url link
Contribution
ACDC,
I can contribute some to get this feature. Others interested?
I can contribute some to get this feature. Others interested?
Henrik (V8 Developer Ed. - Windows)
Straight BASE64 is pretty easy to decrypt, there are many websites around that do this. No point doing something half baked to thwart a "curious" user.
Might be good to do a simple XOR shift by a definable number and then use base 64 encoding.
If you're really paranoid.. maybe use a proper encryption standard and then base 64.
Thoughts?
Might be good to do a simple XOR shift by a definable number and then use base 64 encoding.
If you're really paranoid.. maybe use a proper encryption standard and then base 64.
Thoughts?
yes it is half baked, maybe you are on to something here, if you have a more secure way of doing this then please elaborate....
All I do know is there is a definite need to encrypt url links embedded in outgoing emails and sms messaging, especially with passwords and keeping client information private
All I do know is there is a definite need to encrypt url links embedded in outgoing emails and sms messaging, especially with passwords and keeping client information private
Hi,
I tripped over this site the other day. Would it present a possible solution to what you are trying to achieve? It might also be a way to simplify the main url in order to strip out the port and `AwareIM` folder name in the path?
I don't have much time right now but I suspect that this should work to rewrite the url prior to showing it:
http://www.tuckey.org/urlrewrite/
Cheers,
Pete
I tripped over this site the other day. Would it present a possible solution to what you are trying to achieve? It might also be a way to simplify the main url in order to strip out the port and `AwareIM` folder name in the path?
I don't have much time right now but I suspect that this should work to rewrite the url prior to showing it:
http://www.tuckey.org/urlrewrite/
Cheers,
Pete
Pete Bradstreet
Contract developer of commercialized applications
AwareIM Ver. 8.2
Contract developer of commercialized applications
AwareIM Ver. 8.2
I agree, if its possible to create a more solid solution/protection this is the way to go.intra wrote:Straight BASE64 is pretty easy to decrypt, there are many websites around that do this. No point doing something half baked to thwart a "curious" user.
Might be good to do a simple XOR shift by a definable number and then use base 64 encoding.
If you're really paranoid.. maybe use a proper encryption standard and then base 64.
Thoughts?
Henrik (V8 Developer Ed. - Windows)
Did this feature ever make it in? I just stumbled upon the thread and would be happy to chip in. Although security being a ever growing concern I really think Aware needs a more official support for https certificates & persistent session cookies.
1. the string is protected from 3rd party snooping @ 128bit
2. the app login is protect by either recycling a session token or forcing the user to login if no cookie exists.
3. the data would be protected from second party 'curious' user by what ever privacy rules you have put on the business object.
If that happened you have solid security, not just camouflage. That is something I would put some real money towards.
1. the string is protected from 3rd party snooping @ 128bit
2. the app login is protect by either recycling a session token or forcing the user to login if no cookie exists.
3. the data would be protected from second party 'curious' user by what ever privacy rules you have put on the business object.
If that happened you have solid security, not just camouflage. That is something I would put some real money towards.