I have a form with 2 pages that retrieve information, that information is stored in my header file as hidden values. After the second page the user is directed to a third party payment system. Then they are redirected back to the third page of the form. However, my header does not have the hidden values anymore. how do i gain access to those values, as i do nee them for database purposes.
If the third party payment system you speak of is PayPal, there's a way to set values that they'll send back to you.
However, if the payment system does not have such an API, then I think you're out of luck. It would be their system that generates the headers that would come back to you. It's highly unlikely that their API wouldn't have a way to do it though.
Related
I'm posting a question here but may be even advice is already good.
To be complied with the GDPR, we are now requested by legal department to clarify the data processing for the cookies we use. For each cookie, we need to clarify:
What data it process
Does that data processing involve a server (like sent to the server) or just proceeded locally
Combine with other information to decide if the cookie is processing personal data or not.
Among the cookies we are having on our website, there are 3rd party cookies set by auth0 custom domain, they are:
Now it's really hard for us to fulfill the request because from what we know and from the document we found on auth0 website, the information we're looking for is not available.
Please help to give advice on how should we find the information we're requested.
You'll find some information here: https://auth0.com/docs/manage-users/cookies/authentication-api-cookies. Also I'd advice you to contact Auth0 directly as they are your "processor" and obliged (under the GDPR article 28) to provide you with the information you need. Unless you can read javascript, you need to ask Auth0 for the purpose(s) of each cookie.
The answer for your 2nd question depends on your implementation. If those are 3rd party cookies (set by Auth0), then they always involve a 3rd party server. This means that personal data (IP addresses) are always processed when those cookies are used.
You will get the answer for your 3rd question once you get information on the purposes of each cookie (why they are being set).
Also your legal team would probably want to know the location of those servers (where end users fetch those cookies). As IP-addresses and other traffic data are being processed, it might involve transfers to 3rd countries (and this is where the GDPR gets really complicated).
Currently I set up a RESTful API backend using Django and I can list a set of articles by the following GET:
api/articles/
Also, I can get a single article by:
api/article/1/
Each article is owned by a certain user, and one user could have multiple articles of course.
On the frond end side, I present all the articles at loading of the page, and I hope the user who is logged in currently could see the articles that they own in a different style, e.g, outlined by a box, and has a associated "delete" or "edit" button.
This requires me to tell, after the retrieval of the articles, which ones are owned by the current user programmatically. One way of doing this is to check the current user id with the owner id. However I feel this is not a good choice as the user id is the check is done fully on the client side and may be not consistent with the actual server judgement.
Therefore, is there a way, to tell by looking at the response of the GET, (say, let the server return a property "editable=true/false") to get whether the current user could edit(PUT) the resource?
I understand that this could be done at the server side, by attaching such a property manually. However, I am just asking whether there is better/common practice.
I just started learning web development and I am sorry if the question sounds trivial. Thank you!
You can attach propriety manually as you suggested. The advance of this approach is that you dont need any other http request.
Second possibility might be, that your client intentionally request information about endpoint permissions. In this case I would suggest to use OPTIONS HTTP method. You send OPTIONS HTTP request to api/articles/1 and backend returns wanted info. This might be exactly what OPTIONS method and DRF metadata were made for.
http://www.django-rest-framework.org/api-guide/metadata/
I think that this is a very interesting question.
Several options that come to me:
You can add to the GET api/article/1 response a HTTP header with this information i.e. HTTP_METHODS_ALLOWED=PUT,PATH,DELETE. Doing this way helps the API client because it does not need to know anything else. I think that this is not a good approach when more than one entity is returned.
call to OPTIONS api/article/1. Allowed methods for that user on that resource can be returned but notice that, in my opinion, this approach is not very good in terms of performance, because it duplicates the number of requests to the server.
But what if the entity returned also contains information on the owner or it? can, in this case the client know which policy apply and try to figure out it by itself? notice that the policy can be obtained from another endpoint (just one call would be needed) or even with the login response. If your entities do not contain that kind of information, it could be also returned as a HTTP header (like first option above)
I found that the cookie in browser is a random string which web server sends to each client for remembering users' information purpose. But I don't understand in programmers viewpoint, what does cookie use for?
For example, I've used EditThisCookie extension in Chrome Browser to read wikipedia.org site's cookie, in the following picture included here. The value of this cookie (sessionId) is useless for programmers (EDIT: I mean I don't extract any information from this cookie, I know the cookie is very important for web developers, so sorry about my poor expression). If I get this cookie, which kind of information I can understand about the users?
Looking for some help! Thank you very much!
The example about cookie
http://i102.photobucket.com/albums/m86/dienkun1/cookie_example_zps455f0dad.png
EDIT: Sorry, I've just expressed my problem in wrong way.
Actually, I am going to write an extension for collecting users' preferences via users' cookie, but I can't understand anything what information can be extracted from cookie. I've read about cookie in many documents, like wikipedia, and all of them just show how to get cookie, the definition of cookie, classified... and nothing about which information we can get from cookie.
Thank you very much!
Why do you say that the sessionId is useless for programmers? It actually can be extremely useful. Somewhere on Wikipedia's servers, they're probably storing quite a bit of information about your session. This could include things like whether you've already hidden one of their fundraising banners (so that it won't keep showing it to you again and again), to things that are required for basic functionality, such as what user you are currently logged in as.
However, Wikipedia is storing this same information for millions of sessions. It needs a way to tie the information back to each individual browser. That sessionId is how it does so. It set the sessionId in a cookie when you first accessed the page, and that cookie gets sent back to the server with every request you make to it now. Then they have code on the back end that reads that sessionId from the cookie and uses it to look up all of the information specific to your session, and do whatever needs to be done with it.
You could of course store the session information itself in the cookies, but there are a couple problems with that. First, there are limits on the size of each cookie, and on the overall size of all cookies for a single domain. Some of the data you want to store might not even fit. But the bigger problem is that cookies can be very easily manipulated by the end user. If you stored the information of who the user is logged in as in a cookie, the user could just change that value to something else, and suddenly be logged in as someone else! Of course, it's also possible that the user could change their sessionId to be some other user's session and suddenly be logged in as them. That's why session IDs need to be as random as possible, and should be long enough that guessing someone else's is basically impossible.
Well, why would someone bother writing a sessionId to a cookie if it's useless?
Cookies are extremely useful when it comes to (e.g) identifying users on your site so you can have them logged in right away, count their visits, track them on your site and even beyond.. only to name a few use cases.
To cite a somewhat popular site (wikipedia.org):
Cookies were designed to be a reliable mechanism for websites to remember stateful information (such as items in a shopping cart) or to record the user's browsing activity (including clicking particular buttons, logging in, or recording which pages were visited by the user as far back as months or years ago).
The most important word here is "stateful".
Yesterday I was asked to add the following statement to a website:
Cookies are small text files which are placed on your computer and
remember your preferences/ some details of your visit.
I pushed it back to the editors saying that cookies are not files, but data stored into a file.
They said that the text was based on the BBC cookie's policy page. So I read other pages about it:
https://support.twitter.com/articles/20170514
Wiki says something different (which is what I thought was right):
http://en.wikipedia.org/wiki/HTTP_cookie
Anyone with enough knowledge about the subject to help?
Well, regardless of Twitter or BBC's cookie policy, let's look at Wikipedia's definition:
A cookie, also known as an HTTP cookie, web cookie, or browser cookie, is a small piece of data sent from a website and stored in a user's web browser while the user is browsing that website.
We may indeed just be arguing semantics here, but I think your version is more accurate than the editors' at least in terms of the abstraction being discussed. I'd slightly modify it:
Cookies are not files, but data. Data which may be stored in a file, but data nonetheless.
Now it's entirely possible that every web browser happens to store this data in files. I can't say that with any certainty, but it's possible. The browser isn't required to store it in a file, text or otherwise. It's just required to store the data.
Now, having said that, if this is the language that the customer wants to use on the customer's website, then it's their choice. You are fee to advise them (even, I'd argue, expected to advise them as a professional) but ultimately we're just talking about text copy on a webpage, which the customer defines.
To put it another way... Their policy may be inaccurately worded, but it's their policy. Changing policy is a business decision. From a business perspective it's likely more important that the company's website accurately reflect the company's policy than that it accurately reflect an industry technical definition.
I have a page where user is asked only for the payment amount, then user will be redirected to another website where the payment will be processed, I want the amount to be set on the redirected page without using querystring,cokkie, etc..
I tried to use web service but here is my challange:
user enters amount on the website.
webservice is called and set the amount to ex:400$
then user is redirected without any query string to another website.
Now:
how this payment website will know that this user is the user entered 400$ on the redirecting page?
I can count on approaches more secure than this also.
thanks
I have made some research on net and asked my experienced friends, the answer is "impossible" this way.
Because redirected website somehow identify that user and there is no solution without querystrings or browser related components,
Here is my friend's advice and i am little bit satisfied, not totally :)
He calls this approach as ticketing,
First create a datetime.now integer, with that number add id and amount of money to be processed.
Then make a complex function to encrypt data. take square of every odd digit then divide to 7 etc.
then on the other website, decrypt data and check datetime if its within 5 minutes for example,
the link is valid.
You have to pass the data to the other website somehow.
Cookies wouldn't work due to domain restrictions.
Query string or form posts could work, but you don't want to use query strings.
Alternatively, if both sites share infrastructure, you could use that to share information - for example if they both have access to the same database, you could use that to share data (though you would still need to identify the specific user to both sites).
The way the service would have to work is to give back some token, probably a GUID, that the site will then look for in the querystring of an HTTP request, to identify the owner of that pre-populated data. You then tack that token onto your redirect, and the client makes a request that causes the payment site to go pull the pre-loaded data for that client.
You still have to use a query string, but now, the query string doesn't contain any human-consumable information; they can't identify their $400 amount in the query string and change it to a different amount of money. If they change the GUID at all, the request will most likely fail as that GUID won't exist in whatever datastore of pre-populated data exists behind the payment site.
Contact the website/web service/gateway. They will provide you the API which will define parameters and methods to accept payment amount. If you are the author of such service, provide mechanism to accept such parameters from your caller application. Communication should be secure, using SSL.
For example for payment gateway Paypal, check this for ideas:
Use of the PayPal payment system in ASP.NET
Have a look on wikipedia.
Shortly the answer is impossible this way, because somehow the redirect website should identify the user, all the ways are browser related or ip ( which can cause many issues later)